NFS client slow on amd64 6.2-PRERELEASE #2
Jeremy Chadwick
freebsd at jdc.parodius.com
Thu Oct 5 16:14:07 UTC 2006
On Thu, Oct 05, 2006 at 05:28:03PM +0200, Heinrich Rebehn wrote:
>root at antsrv1 [/tmp] # time dd if=/dev/zero of=/mnt/x/10MB.dat bs=1M count=10
>10485760 bytes transferred in 4.967248 secs (2110980 bytes/sec)
>
>root at antsrv1 [/tmp] # time dd if=/dev/zero of=/mnt/x/100MB.dat bs=1M count=100
>104857600 bytes transferred in 69.020366 secs (1519227 bytes/sec)
>
>root at antsrv1 [/tmp] # time dd if=/dev/zero of=/mnt/x/10MB.dat bs=1M count=10
>10485760 bytes transferred in 5.289492 secs (1982376 bytes/sec)
>
>root at antsrv1 [/tmp] # time dd if=/dev/zero of=/mnt/x/100MB.dat bs=1M count=100
>104857600 bytes transferred in 58.715595 secs (1785856 bytes/sec)
This isn't a valid test of performance, in my opinion. bs=1M is a
bad idea. You shouldn't be using dd for this kind-of test at all.
I should also note that bs=1M is not the same thing as obs=1M ibs=1M.
dd's weird like that (someone can explain it, I'm sure -- I've seen
it discussed in the pasT).
scp is an ""acceptable"" real-life test (not the best, but it's
legitimate), and you only did it from antsrv1 --> antsrv2, not the
other direction. It's really too bad the OpenBSD guys refuse to
incorporate the HP (high-performance) patches into OpenSSH, and
being able to say "-c none" would *really* help when it comes to
benchmarking network I/O via scp (in our case, we do dump over ssh
across a segregated private LAN -- the encryption overhead slows
our backups down to a crawl, and is worthless in our environment
since as I said, segregated private LAN...)
That said:
I have seen cases where network peformance on BSD works fantastic
uni-directionally -- for example, using FTP to "get" a file from
a FreeBSD box on a 100mbit LAN results in a speed of about
300-400kbit/sec, while doing a "put" to the same box results in
90mbit/sec.
The problem in that case turned out to be duplex-related. Both
boxes were auto-negotiating with the Cisco switch correctly, and
indeed the Cisco labelled them as auto-100/full, but as anyone who
is familiar with Ciscos knows, auto-negotiation on Catalysts is
far from reliable. Both boxes reported auto-neg and being at 100/full
as well. I ended up hard-setting the boxes to use 100/full, and
set the switch ports to 100/full, then rebooted both boxes (yes,
this is sometimes required, as driver auto-neg code is a bit tweaky);
voila, problem fixed.
If you can connect these two boxes directly via a crossover cable,
and you still see the problems, then yes, there's something definitely
amiss that needs investigating. :-)
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
More information about the freebsd-stable
mailing list