Subject: Re: TCP send/ack lockstep problem

From: Stephen Hemminger <[email-masked]>
Date: Fri, 01 Sep 2006 23:15:25 -0700

Matthias Urlichs wrote:
> Hi,
>
> Herbert Xu:
>   
>> Matthias Urlichs <[email-masked]> wrote:
>>     
>>> Any ideas? Is the sending program doing something stupid? If so, what?
>>>       
>> Probably.  Since you're on the sender's side (192.109.x.x I presume) why
>> don't you do a strace on the sending process and tell us?
>>
>>     
> The stuff I see in there doesn't look stupid to me.
>
> accept(...) = 216
> setsockopt(216, SOL_IP, IP_TOS, [8], 4) = 0
> setsockopt(216, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> setsockopt(216, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
> followed by a bunch of "interactive" read() and write() calls, and then
> a rather long sequence of 16384-byte writes (all of which end up being
> partial because the send buffer size is 12k).
>
> so if one of these is the cause for the observed lockstep behavior when
> the send buffer is *full*, I'd consider that to be a bug.
>
> Interestingly, the *sender* advertizes window that's (a bit more than) one MTU:
>
> 07:47:03.204939 IP (tos 0x38, ttl  64, id 41217, offset 0, flags [DF], proto: TCP (6), length: 1468) 192.109.102.42.3306 > 62.193.238.120.53138: . 167089:168505 (1416) ack 0 win 1424 <nop,nop,timestamp 218027038 834794727>
>
> but that's the other direction -- is something in the kernel confused about
> which window variable to use ??
>
>   
You could try turning off window scaling:
    sysctl -w net.ipv4.tcp_window_scaling=0
If that fixes it, you have a corrupting middlebox in the path or bad 
implementation on the other end.

Also try turning off tcp_abc (on the sender).
    sysctl -w net.ipv4.tcp_abc=0

-- 
VGER BF report: H 0.050318