tcp window size

[slydmin]

I am having some problems with TCP window size on my linux boxes. No matter what settings I use for tcp_rmem/tcp_wmem rmem_max/wmem/max, the TCP window for a file transfer always stays at 5820 bytes.

The tcpdump (checking for ACK bit ) confirms that the window size is ~5k with a scaling factor of 8 (2^8=256). On subsequent transfers, the window size drops to 23. (23*256=5888) sounds like the correct size of window, although never exceeds the 5888 bytes value.

I have tried ridiculously large values (16M) for tcp_rmem/wmem, however not been able to change that window size of 5820. Is there a way to make this window size 64k with scaling of 256?


I am using the following values for TCP windows:

net/core/rmem_max = 8738000
net/core/wmem_max = 6553600

net/ipv4/tcp_rmem = 8192 873800 8738000
net/ipv4/tcp_wmem = 4096 655360 6553600

(as per this website: http://www.acc.umu.se/~maswan/linux-netperf.txt)

both servers are OEL4 U4 with near identical hardware.

Any comments?

[rick jones]

Can you post a snippet of the packet trace showing the SYN segments and the first few data packets?

Is your application making direct setsockopt() calls?

Without a direct setsockopt() call, the TCP stack in linux will attempt to "autotune" the window size by guesstimating the sender's congestion window and by looking at the rate at which the receiving application is consuming data in relationship to the presume bandwidth delay product of the connection.

Also, just looking at the ACKs during the transfer will show the window updates as they slide along. Unless the receiver completely drains the SO_RCVBUF it is unlikely you will see a very large value in the window field, even if the window is growing/grown. To see how much window the sender believes he has, you have to look at the sending side, and compare the sequence numbers in the arriving ACKs with the sequence numbers of the segments the sender transmits in response.

You might also consider running your tcpdump traces through tcptrace. That can generate some summary reports about the connection as well as some pretty pictures you can run through the "right" xplot or a tcptrace'sxplot to gnuplot converter.