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:0.481 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site