window sizes and buffer sizes (Re: changing default window sizewin2k)
On Wed, 17 Dec 2003, Kevin Gibbs wrote:
> Windows does not let application level changes to the TCP algorithm
> parameters. As such the window size that iperf reports is simply a buffer
> size and has nothing to do what Windows uses for window sizes. Performance
> can be gained by setting this buffer larger from the commandline, but it
> is not the TCP window size that you are changing. Microsoft is pretty
> explicit about this in their docs.
I am sorry to add some confusion to this (at least at first sight)
but, when everything is ok (i.e.: forget everything about the strange
case above for the moment), the so-called -w "window size" of iperf is
_also_ setting "simply a buffer size", and neither setting a "window"
size.
From "man 7 socket" on linux debian 2.2:
SO_SNDBUF
Sets or gets the maximum socket send buffer in bytes. The default
value is set by the wmem_default sysctl and the maximum allowed
value is set by the wmem_max sysctl.
SO_RCVBUF
Sets or gets the maximum socket receive buffer in bytes. The default
value is set by the rmem_default sysctl and the maximum allowed
value is set by the rmem_max sysctl.
Of course, this buffer sizes are upper bounds to window sizes
variations later during the transfer, so there are of utmost
importance! iperf is wise to provide this vital -w option. Only the
name of the option is wrong: it is not "a window size" strictly
speaking but a socket buffer size, or a "*maximum* window size" if you
prefer.
The variations of window sizes during the transfer depend on other
factors than the buffer size. For instance:
From: <http://www.csm.ornl.gov/~dunigan/netperf/auto.html>
The Linux 2.4 advertised receive window starts small (4 segments) and
grows by 2 segments with each segment from the transmitter, even if a
setsockopt() has been done for the receiver window.
Dunigan's pages are a good start for more information on this subject.
The difference between win32 and the rest seems to be: on the rest,
the buffer size given is _really_ used by the protocol :-)
Cheers,
Marc.