asymmetric NFS transfer rates

[Doug White]

On Tue, 2 Nov 2004, Robert Watson wrote:

>
> 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.

It'd also be nice to know the mount options (nfs blocksizes in
particular).


-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite at gumbysoft.com          |  www.FreeBSD.org