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