>Number:         12525
>Category:       kern
>Synopsis:       Request to change the default NFS_WSIZE and NFS_RSIZE back to 8k
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 01 19:21:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Thilo Manske
>Release:        current since 19th Sep. 2000
>Organization:
Dies ist Thilos Unix Signature! Viel Spass damit.
>Environment:
System: many 
Architecture: see below
Machine: see below
>Description:
The default NFS "read size" and "write size" have been increased from 8k to 32k six
months ago.

This does probably boost NFS throughput on machines with NICs that have
buffers bigger than 32k or are fast enough to prevent buffer overruns, but
unfortunatly this is too large for many, many other machines and causes big
problems like slower, unreliable or even stalling NFS connections.

Because of that and since as NetBSD user I expect things like NFS to "just
work" without much hacking I humbly request to set the defaults back to 8k.

Here are some examples with ports/machines that have troubles with the
current R/W sizes:

sparc:	The onboard NIC of all sun4c's and sun4m's I've encountered so far
	have only 8 receive buffers. But a boost of 32k are at least
	21 ethernet frames!
sun3:	I guestimate, that the same (8 receive buffers) is true for most
	Sun 68k machines,
newsmips:  Same story with my NWS3410, don't know for other newsmips
	machines.
news68k:  I would be suprised, if that range of machines had better
	network interfaces than a NWS3410.
hp300:	I browsed the mailinglists and bug database for some dmesg outputs
	and found "8 receive buffers" there as well.
arm26 and
arm32:	Although the Etherlan 602 NIC of my RISC PC has a 32k buffer I
	already get a lot of "receiver ring buffer overruns" with smaller
	R/WSIZES. 
	(And AFAIK this NIC is probably one of the bests for Acorns;
	most NICs for Acorn computers have smaller buffers.)
	Oh, I have a StrongARM, so it's not a matter of slow CPU.
dreamcast:  I've read in one of the mailinglists, that dreamcasts won't even
	boot on 100MBit/s networks...
i386 and
mac68k:	Slow machines and/or poor ethernet interfaces are not that uncommon
	here.

AFAIK a RSIZE of 32k is OK for pmax and vax, since those machines usually
have 32 receive buffers. Alphas probably as well (with the exception of some
AXPpci33, since they don't have on board NICs).

But: As far as I understand NetBSD's NFS it doesn't make much sense to change 
NFS_RSIZE (or NFS_WSIZE) only on some ports. E.g. wouldn't a pmax with a write
size of 32k cause troubles with a sparc (and 8 receive buffers) as NFS
server? (I may be wrong here, please correct me!)

On a related note:
So far only the option NFS_BOOT_RWSIZE has been documented in options(4),
the new "NFS_WSIZE" and "NFS_RSIZE" should be mentioned there as well.
	
>How-To-Repeat:
>Fix:
The current work around is to put
	options	NFS_RSIZE=8192
	options NFS_WSIZE=8192
in every kernel config file.

Or make heavy use of -I=8192 and/or -w=8192 in your fstabs and
use option NFS_BOOT_RWSIZE in kernels for diskless machines.

Or use tcp mounts.

But I honestly think that changing the values in .../sys/nfs/nfs.h back is
better. This will work for (nearly) everyone (it has worked before, hasn't
it?), and people can still tune NFS by choosing larger read or write sizes,
if they want to -- either with kernel options or mount_nfs's -I & -w.

New sysctls for setting the defaults for (future) NFS mounts may be nice as
well.  Something like sysctl -w vfs.nfs.readsize=<whatever>.

*OR*

Develope a clever algorithm that changes the read/write sizes dynamically
for best performance/reliability so that poor users/admins don't have to
care about all this at all :-)
>Release-Note:
>Audit-Trail:
>Unformatted: