Matthias Urlichs wrote:
Hi,
Herbert Xu:
Matthias Urlichs <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
