Date: Tue, 20 Mar 2001 11:11:10 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Gordon Tetlow <gordont@bluemtn.net>, Jan Conrad <conrad@th.physik.uni-bonn.de>, freebsd-stable@FreeBSD.ORG Subject: Re: NFS performance Message-ID: <200103201911.f2KJBAR96066@earth.backplane.com> References: <Pine.BSF.4.33.0103201911530.405-100000@merlin.th.physik.uni-bonn.de> <Pine.BSF.4.33.0103201041190.3344-100000@sdmail0.sd.bmarts.com> <20010320105404.D29888@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
:Actually, from what I've been told, TCP allows for much larger requests
:than what UDP does, afaik UDP maxes out at 8k while tcp should be able
:to go to 32k (maybe 64k) and give possibly better performance.
:
:Plus each time you 'hickup' under a UDP mount it's a lot more painful
:because since it's possible for each RPC to be broken into several
:packets you have a lot more retransmition to do.
Depends on what kind of LAN you have. A standard 100BaseT network still
has a 1536 byte packet size limit, so even 8K UDP NFS packets will be
fragmented. The fragmentation is avoided with TCP, even though as many
packets will be sent. This is why TCP mounts tend to have very
comparable performance to UDP mounts. Under very heavily loaded
conditions TCP could very well be the better choice because the TCP
layer handles load a whole lot better then the NFS udp/timeout/retry
layer and the kernel isn't really tuned to deal with hundreds of clients
all sending fragmented packets at the same time.
I wouldn't bother with larger NFS block sizes, even over TCP, unless
you are running a much faster LAN (e.g. gigabit).
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200103201911.f2KJBAR96066>