Updating our TCP and socket sysctl values...

[Alexander Leidinger]

On Sat, 19 Mar 2011 11:58:12 -1000 (HST) Jeff Roberson
<jroberson at jroberson.net> wrote:

> On Sat, 19 Mar 2011, Alexander Leidinger wrote:
> 
> > On Sat, 19 Mar 2011 15:37:47 +0900 George Neville-Neil
> > <gnn at neville-neil.com> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Howdy,
> >>
> >> I believe it's time for us to upgrade our sysctl values for TCP
> >> sockets so that they are more in line with the modern world.  At
> >> the moment we have these limits on our buffering:
> >>
> >> kern.ipc.maxsockbuf: 262144
> >> net.inet.tcp.recvbuf_max: 262144
> >> net.inet.tcp.sendbuf_max: 262144
> >>
> >> I believe it's time to up these values to something that's in line
> >> with higher speed local networks, such as 10G.  Perhaps it's time
> >> to move these to 2MB instead of 256K.
> >>
> >> Thoughts?
> >
> > I suggest to read
> >  http://www.bufferbloat.net/projects/bloat/wiki/Bufferbloat
> > and do a before/after test to make sure we do not suffer from the
> > described problem. Jim Getty has test descriptions:
> >  http://gettys.wordpress.com/category/bufferbloat/
> 
> Are they not talking about buffers in non-endpoint devices?  Or

They are talking about every place where buffering instead of
package-loss (= triggering the congestion algorithm) happens. If you
connect via a wireless device, it may even your transmitting device
which may be doing something wrong. You may commonly experience this in
non-endpoint devices, as those are more likely to be in a congested
situation than the endpoint devices, but there is still research going
on to completely understand this.

The FAQ (so far):
http://gettys.wordpress.com/bufferbloat-faq/

Some changes made to a NIC to see a little bit the direction:
http://gettys.wordpress.com/2011/02/13/bufferbloat-related-patches-for-the-iwl3945/

The description of an experiment with a WLAN-AP:
http://gettys.wordpress.com/2010/12/02/home-router-puzzle-piece-two-fun-with-wireless/

> perhaps even overly large rx queues in endpoints, but not local
> socket receive buffers?  It seems that they are describing situations

Yes, the RX buffers on an endpoint are not an issue. If the specific
buffers in this thread are an issue... I don't know.

> where excessive buffering masks network conditions until it's too
> late.

Bye,
Alexander.