[lkml]   [2000]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
   Date: Tue, 7 Nov 2000 10:41:36 +0100
From: Andi Kleen <>

I think such a theory would at least need verifying (e.g. by a
sniffer on the windows end that checks checksums or someone finding
the checksum failed counters windows probably maintains)


BTW, note the pattern of the win98 logs, basically the whole
connection from the WIN98 side is:

LINUX data(N) --> win98 DIFFERENT sequence number
LINUX data(N+1) --> win98 DIFFERENT sequence number


LINUX data(N) --> win98 SAME sequence number
win98 ACK N --> LINUX

N++; goto repeat

And in all cases except the first data segment sent by Linux, the
sequence numbers are corrupted such that the original 536 byte payload
is reduced to a 534 byte payload.

Now one could argue it might be a bandwidth limiter, because the
first change in sequence numbers is:

22:34:36.069773 > P 1:19(18) ack 44 win 5840 (DF)
22:34:36.069837 > P 19:553(534) ack 44 win 5840 (DF)

They're changed, but lined up. However later we get stuff like:

22:34:39.245138 > P 21:555(534) ack 44 win 5840 (DF)
22:34:39.245208 > P 557:1091(534) ack 56 win 5840 (DF)

Which don't even line up at all. Furthermore, if the checksums were
correct win98 should have ACK'd fully the <1:19> data packet and the
<19:553> one. Also for the non-contiguous cases win98 should have
sent an immediate ACK (and a SACK block indicating the non-contiguous
data received).

Now, I could see some buggy bandwidth limiter chopping up the sequence
numbers such that they aren't lined up occaisionally, but corrupting
all the TCP checksums as well? I find that hard to believe.

Well, if it is what's happening, I wouldn't expect such a company to
be making such products for long :-)

David S. Miller
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.032 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site