Date: Tue, 2 Nov 2004 13:14:56 -0500 (EST) From: Robert Watson <rwatson@freebsd.org> To: Emanuel Strobl <Emanuel.Strobl@gmx.net> Cc: freebsd-current@freebsd.org Subject: Re: asymmetric NFS transfer rates Message-ID: <Pine.NEB.3.96L.1041102131322.21044C-100000@fledge.watson.org> In-Reply-To: <200411021905.08044.Emanuel.Strobl@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041102131322.21044C-100000>