> If he is using UDP rather than TCP
> as the transport layer, another potential issue is that 32K requests will
> end up as IP packets with a very large number of fragments, potentially
> exposing some kind of network stack bug in which the last fragment is
> dropped or corrupted.
Actually it is worse that that, and IMHO 32k UDP requests are asking for
trouble.
A 32k UDP datagram is about 22 ethernet packets. If ANY of them is
lost on the network, then the entire datagram is lost. NFS must
regenerate the request on a timeout. The receiving system won't
report that it is missing a fragment.
If fragments are being lost, the receiving system also starts to hit
a buffer crisis because of all the incomplete requests it is still
hoping it might receive the missing fragment for. After all the IP
layer won't know the retransmittion is anything special.
There are also an lot of ethernet cards out there which don't have
enough buffer space for 32k of receive data. Not to mention the
fact that NFS can easily (at least on some systems) generate
concurrent requests for different parts of the same file.
I would suggest reducing the size back to 8k, even that causes
trouble with some cards.
It should also be realised that transmitting 22 full sized, back
to back frames on the ethernet doesn't do anything for sharing
the bandwidth betweenn different users. The MAC layer has to very
aggressive in order to get a packet in edgeways (so to speak).
David
--
David Laight: david@l8s.co.uk