lkml.org 
[lkml]   [2004]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Slow NFS performance over wireless!
    From
    Date
    På on , 14/01/2004 klokka 20:12, skreiv Miquel van Smoorenburg:
    > On an NFS client (2.6.1-mm3, filesystem mounted with options
    > udp,nfsvers=3,rsize=32768,wsize=32768) I get for the same share as
    > write/rewrite/read speeds 36 / 4 / 38 MB/sec. CPU load is also
    > very high on the client for the rewrite case (80%).
    >
    > That's with back-to-back GigE, full duplex, MTU 9000, P IV 3.0 Ghz.
    > (I tried MTU 5000 and 1500 as well, doesn't really matter).
    >
    > Is that what would be expected ?

    Err.. no...

    I didn't have a 2.6.1-mm3 machine ready to go in our GigE testbed (I'm
    busy compiling one up right now). However I did run a quick test on
    2.6.0-test11. Iozone rather than bonnie, but the results should be
    comparable:

    Iozone: Performance Test of File I/O
    Version $Revision: 3.169 $
    Compiled for 32 bit mode.
    Build: linux

    Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
    Al Slater, Scott Rhine, Mike Wisner, Ken Goss
    Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
    Randy Dunlap, Mark Montague, Dan Million,
    Jean-Marc Zucconi, Jeff Blomberg.

    Run began: Wed Jan 14 21:32:08 2004

    Include close in write timing
    File size set to 2097152 KB
    Record Size 128 KB
    Command line used: /plymouth/trondmy/public/programs/fs/iozone -c -t1 -s 2048m -r 128k -i0 -i1
    Output is in Kbytes/sec
    Time Resolution = 0.000001 seconds.
    Processor cache size set to 1024 Kbytes.
    Processor cache line size set to 32 bytes.
    File stride size set to 17 * record size.
    Throughput test with 1 process
    Each process writes a 2097152 Kbyte file in 128 Kbyte records

    Children see throughput for 1 initial writers = 109333.84 KB/sec
    Parent sees throughput for 1 initial writers = 109326.48 KB/sec
    Min throughput per process = 109333.84 KB/sec
    Max throughput per process = 109333.84 KB/sec
    Avg throughput per process = 109333.84 KB/sec
    Min xfer = 2097152.00 KB

    Children see throughput for 1 rewriters = 111377.63 KB/sec
    Parent sees throughput for 1 rewriters = 111370.21 KB/sec
    Min throughput per process = 111377.63 KB/sec
    Max throughput per process = 111377.63 KB/sec
    Avg throughput per process = 111377.63 KB/sec
    Min xfer = 2097152.00 KB

    Children see throughput for 1 readers = 123864.27 KB/sec
    Parent sees throughput for 1 readers = 123854.96 KB/sec
    Min throughput per process = 123864.27 KB/sec
    Max throughput per process = 123864.27 KB/sec
    Avg throughput per process = 123864.27 KB/sec
    Min xfer = 2097152.00 KB

    Children see throughput for 1 re-readers = 167226.50 KB/sec
    Parent sees throughput for 1 re-readers = 167222.79 KB/sec
    Min throughput per process = 167226.50 KB/sec
    Max throughput per process = 167226.50 KB/sec
    Avg throughput per process = 167226.50 KB/sec
    Min xfer = 2097152.00 KB


    That is admittedly with a (very fast) NetApp filer on the receiving end,
    so it is only a Linux client test. However as you can see, I'm basically
    flat w.r.t. rereads and rewrites. Client is BTW a PowerEdge 2650 w/
    built-in Broadcom BCM5703 (no jumbo frames). Note: with TCP, the numbers
    degrade a bit to 81MB/sec write, 82MB/sec rewrite, 135MB/sec read and
    144MB/sec reread.

    Against a Sun server, I get something a lot slower: 32MB/sec write,
    22MB/sec rewrite, 38MB/sec read, 28MB/sec reread using UDP, 29/21/29/26
    using TCP. There I do indeed see a slight dip in both the rewrite and
    the reread figures.



    1 question:
    - Is bonnie doing a close() or an fsync() of the file after if
    finishes the write, and before it goes on to testing for rewrites? I
    suspect not, in which case your numbers will be strongly skewed.


    Cheers,
    Trond
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:00    [W:4.433 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site