On Wed, 17 May 2006, Constantinos Makassikis wrote:
> On 5/15/06, Stephen Hemminger <shemminger@xxxxxxxx> wrote:
>
> > > Indeed, but aren't tcp-rmem/tcp_wmem taken into account only when
> > > autotuning is enabled ?
> >
> > The tcp_rmem[2] and tcp_wmem[2] are still an upper bound on the allowed
> > socket memory.
>
> From Documentation/networking/ip-sysctl.txt
>
> <<
> tcp_wmem - vector of 3 INTEGERs: min, default, max
> .
> .
> .
> max: Maximal amount of memory allowed for automatically selected
> send buffers for TCP socket. This value does not override
> net.core.wmem_max, "static" selection via SO_SNDBUF does not use this.
> Default: 128K
> >>
>
> I am really lost NOW :-(
It is confusing. I had also noticed before that the advertised receive
window was only 75% of the requested value, but I think I may understand
it now. As you note above, when using SO_{SND,RCV}BUF to explicitly set
the socket send or receive buffer space, the tcp_{rmem,wmem} settings
are not used, but rather the net.core.{rmem,wmem}_max values are used
instead.
>From your earlier post:
> > > 5) Why does the advertized window remain stuck at 6 MBytes ?
> > tcp_wmem
>
> Autotuning is normaly disabled (cf. 1), 2), 4))
> According to man tcp, it seems that by default linux tcp reserves 1/4
> of the receive buffer for buffering overhead. This is conditioned by
> tcp_adv_win_scale variable.
> Thus, the "real" receive buffer size is actually 12 Mbytes from which
> only half is advertised ...
> Still it doesn't explain why only half is advertised ...
So you only actually get 3/4 of what you requested (doubled) for the
actual advertised receive window, up to the maximum defined by
net.core.{rmem,wmem}_max.
>From your original post:
> net/core/rmem_max=8388608
> net/core/wmem_max=8388608
So you have specified a maximum of 8 MB, and I'm assuming that this
maximum is an actual maximum and isn't itself doubled. And I'm also
assuming that this maximum also includes 1/4 overhead, which means
that the actual maximum advertised receive window on the network would
be 3/4 * 8 MB or 6 MB, which is what you're observing, and what I've
also observed.
This is my best educated guess at this point for explaining this
behavior. I haven't actually examined any of the actual Linux kernel
TCP stack code.
-Hope this helps
-Bill
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
