asymmetric NFS transfer rates

[Robert Watson]

On Tue, 2 Nov 2004, Emanuel Strobl wrote:

> It's a IDE Raid controller (3ware 7506-4, a real one) and the file is
> indeed huge, but not abnormally. I have a harddisk video recorder, so I
> have lots of 700MB files. Also if I copy my photo collection from the
> server it takes 5 Minutes but copying _to_ the server it takes almost 15
> Minutes and the average file size is 5 MB. Fast Ethernet isn't really
> suitable for my needs, but at least the 10MB/s should be reached. I
> can't imagine I get better speeds when I upgrade to GbE, (which the
> important boxes are already, just not the switch) because NFS in it's
> current state isn't able to saturate a 100baseTX line, at least in one
> direction. That's the real anstonishing thing for me. Why does reading
> staurate 100BaseTX but writes only a third? 

Have you tried using tcpdump/ethereal to see if there's any significant
packet loss (for good reasons or not) going on?  Lots of RPC retransmits
would certainly explain the lower performance, and if that's not it, it
would be good to rule out.  The traces might also provide some insight
into the specific I/O operations, letting you see what block sizes are in
use, etc.  I've found that dumping to a file with tcpdump and reading with
ethereal is a really good way to get a picture of what's going on with
NFS: ethereal does a very nice job decoding the RPCs, as well as figuring
out what packets are related to each other, etc.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Principal Research Scientist, McAfee Research