That’s not actually true, for two reasons.
One is that if you use excessively large rsize and wsize with UDP you end up with a rather large number of IP fragments - if even one fragment is lost due to packet loss the UDP packet can’t be reassembled and the whole lot needs to be sent again. The more fragments you send per packet the higher the chance of packet loss hitting one of the fragments, and the more data you have to go back and resend.
If you have zero packet loss it doesn’t matter, but if you have a small amount of packet loss (such as a wireless network) then performance can suffer greatly with an excessive number of fragments. Therefore for UDP wsize and rsize should not be set any bigger than the point of diminishing returns.
The second reason is rsize and wsize in UDP mode is the effective window size for nfs3, and just like TCP window size, if its too small to satisfy the bandwidth/delay product performance will suffer.
There is certainly some benefit to reducing protocol overhead but IMO the window size effect is more important - if the rsize / wsize is too small for the round trip time you get a lot of “dead time” where no data is not being sent.[quote=“THEM, post:15, topic:14076”]
The main thing is that “you” (as in “The User”) can never know as much as the kernel about what it can do best. The read and write buffer sizes are negotiated mutually between client and server as to what should work best for that combination under these circumstances. Well, assuming the porting team did their job right anyway
[/quote]
I can’t agree there - manual tuning of network parameters to suit a specific network and device situation is always going to trump “defaults” in the protocol and/or kernel.
I can assure you that whatever the default was when I was doing the Raspberry Pi 1 testing, it was far from optimal, with throughput less than half of what I ended up with after I had tuned rsize and wsize. For that specific test situation 8192 was optimal in the sense that going higher only gave very tiny incremental increases in throughput at the expense of much greater risk of performance loss in the face of packet loss.
I am in no way suggesting that 8192 is a magic number for any other situation. Part of the optimisation on the Pi 1 was really to work around the very slow CPU - it is actually slow enough that the overheads of TCP itself when trying to play back video was enough to slow things down dramatically. Most of the performance benefit came from switching to UDP, which is not the case on devices with much more powerful CPU’s.