Re: glibc aio performance

["Don Capps" <don dot capps2 at verizon dot net>]

Amos,

    Ok... You're getting closer to the right result. Now for some
    questions.

    1. How much memory is in the system ?
    2. What is the type and speed of your processor ?
        Mine was 933 Mhz P3. This helps reduce the time
        spent in spawning async I/O threads :-)
    3. What is the filesystem type ? ext2, ufs....
    4. What version of Iozone are you using ?
        See: iozone -v
    5. Is the filesystem on a single disk or is it striped ?

    Your latest results are much better now. No longer off
    by a factor of 4 or 5 X. but now down to 30 or 40 %.
    I suspect that with a bit more info we can track down
    the cause of this as well. I'll still go with more
    understanding of the system and the testing than
    any problems in glibc or Iozone. :-)

    Thanks,
    Don Capps

----- Original Message -----
From: "Amos P Waterland" <waterland@us.ibm.com>
To: "Don Capps" <don.capps2@verizon.net>
Cc: <libc-alpha@sources.redhat.com>; "Thomas Gall" <tom_gall@vnet.ibm.com>
Sent: Thursday, May 30, 2002 4:46 PM
Subject: Re: glibc aio performance


>
> Don:
>
> Thank you very much for your analysis.  I have a few questions.
>
> I ran the suggested options on my Redhat 7.3 box, and got the following
> results.  (I noticed that in your results, your second command line had -s
> 200M, but the report had 307200: maybe the 2 was just a typo in the
email?)
>
> % iozone -r 64 -s 300M -i 0 -i 1
> KB  reclen   write rewrite    read    reread
> 307200      64   32881   32494    42239    43256
> % iozone -k 32 -r 64 -s 300M -i 0 -i 1
> KB  reclen   write rewrite    read    reread
> 307200      64   18548   19151    26866    26512
>
> As you can see, the results are much better, but the AIO is still 30-40%
> slower than the SIO.  (I re-ran the tests several times to try to iron out
> timing anomalies.)  Do you think that thread setup, teardown, and overhead
> accounts for this?  (I did try using just two threads, but did not get
> significantly better throughput.)
>
> Thanks in advance.
>
> Amos Waterland
>
>
>
>
>