Re: network outages

[email protected] (Greg Troxel) writes:

>  user sets 1 MB default send/recv space, doesn't know or remember about
>  sbmax

There are plenty of unreasonable settings. Ask for a Gigabyte and the
system may hang or panic when it runs out of kernel memory.


>Are you just pointing out that "bytes available for socket data
>(sendspace)" is not the same as "bytes used for storing socket data
>(sbmax)"?   And thus that this situation is confusing?

It's confusing since both values are related but not the same
thanks to that correction factor to account for mbuf headers.


>I can see the stopgap point historically.  256K was a high fraction of
>the memory on a vax (1M to 32M, absent the late-stage monsters, iirc).

Any fixed number is a high fraction somewhere.


>But we are in a world where NetBSD can run on 128M to 512G and picking a
>fixed limit is tricky.  I think it makes sense to make it a clamping
>limit instead of a rejection limit.

Maybe, but still confusing, especially to people who don't even know
that kern.sbmax exists and that wonder why autoscaling doesn't work :)


>I wonder how much the surprisingly low sbmax explains my long-term
>perception that NetBSD TCP is slow and that auto buf sizing doesn't
>really work.

kern.sbmax is actually a high value, compared to TCP buffers
of 32k or 64k, and these defaults are perfectly fine and
recommended for a system in a LAN of up to 1Gbps.

N.B. recommendations for TCP autoscaling should always
reference kern.sbmax and also kern.mbuf.nmbclusters,
which is another limit (and in former times only a kernel
option).