* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:03 ` David S. Miller
@ 2000-11-07 6:44 ` Jordan Mendelson
2000-11-07 6:56 ` David S. Miller
` (3 subsequent siblings)
4 siblings, 0 replies; 30+ messages in thread
From: Jordan Mendelson @ 2000-11-07 6:44 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, kuznet
[-- Attachment #1: Type: text/plain, Size: 847 bytes --]
"David S. Miller" wrote:
>
> Date: Mon, 06 Nov 2000 22:13:23 -0800
> From: Jordan Mendelson <jordy@napster.com>
>
> There is a possibility that we are hitting an upper level bandwidth
> limit between us an our upstream provider due to a misconfiguration
> on the other end, but this should only happen during peak time
> (which it is not right now). It just bugs me that 2.2.16 doesn't
> appear to have this problem.
>
> The only thing I can do now is beg for a tcpdump from the windows95
> machine side. Do you have the facilities necessary to obtain this?
> This would prove that it is packet drop between the two systems, for
> whatever reason, that is causing this.
Attached to this message are dumps from the windows 98 machine using
windump and the linux 2.4.0-test10. Sorry the time stamps don't match
up.
Jordan
[-- Attachment #2: lin240.log --]
[-- Type: text/plain, Size: 3244 bytes --]
23:36:15.252817 209.179.194.175.1084 > 64.124.41.179.8888: S 370996:370996(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
23:36:15.252891 64.124.41.179.8888 > 209.179.194.175.1084: S 3050526223:3050526223(0) ack 370997 win 5840 <mss 1460,nop,nop,sackOK> (DF)
23:36:16.159685 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1 win 8576 (DF)
23:36:16.160461 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1 win 65280 (DF)
23:36:16.160488 209.179.194.175.1084 > 64.124.41.179.8888: P 1:44(43) ack 1 win 65280 (DF)
23:36:16.160506 64.124.41.179.8888 > 209.179.194.175.1084: . ack 44 win 5840 (DF)
23:36:16.261533 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF)
23:36:16.261669 64.124.41.179.8888 > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF)
23:36:19.261055 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF)
23:36:19.450762 209.179.194.175.1084 > 64.124.41.179.8888: P 44:56(12) ack 21 win 65260 (DF)
23:36:19.450788 64.124.41.179.8888 > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF)
23:36:19.450820 64.124.41.179.8888 > 209.179.194.175.1084: P 557:1093(536) ack 56 win 5840 (DF)
23:36:22.281248 209.179.194.175.1084 > 64.124.41.179.8888: P 44:456(412) ack 21 win 65260 (DF)
23:36:22.281308 64.124.41.179.8888 > 209.179.194.175.1084: . ack 456 win 6432 <nop,nop, sack 1 {44:56} > (DF)
23:36:25.441061 64.124.41.179.8888 > 209.179.194.175.1084: P 21:557(536) ack 456 win 6432 (DF)
23:36:25.701796 209.179.194.175.1084 > 64.124.41.179.8888: . ack 557 win 65280 (DF)
23:36:25.701841 64.124.41.179.8888 > 209.179.194.175.1084: P 557:1093(536) ack 456 win 6432 (DF)
23:36:25.701859 64.124.41.179.8888 > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF)
23:36:37.701091 64.124.41.179.8888 > 209.179.194.175.1084: P 557:1093(536) ack 456 win 6432 (DF)
23:36:38.026766 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1093 win 65280 (DF)
23:36:38.026826 64.124.41.179.8888 > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF)
23:36:38.026839 64.124.41.179.8888 > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF)
23:37:02.021068 64.124.41.179.8888 > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF)
23:37:02.328163 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1629 win 65280 (DF)
23:37:02.328189 64.124.41.179.8888 > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF)
23:37:50.321057 64.124.41.179.8888 > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF)
23:37:50.673000 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1847 win 65062 (DF)
23:37:50.673068 64.124.41.179.8888 > 209.179.194.175.1084: P 1847:1868(21) ack 456 win 6432 (DF)
23:38:00.162380 209.179.194.175.1084 > 64.124.41.179.8888: F 456:456(0) ack 1847 win 65062 (DF)
23:38:00.181055 64.124.41.179.8888 > 209.179.194.175.1084: . ack 457 win 6432 (DF)
23:38:00.187291 64.124.41.179.8888 > 209.179.194.175.1084: F 1868:1868(0) ack 457 win 6432 (DF)
23:38:00.363357 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1847 win 65062 <nop,nop, sack 1 {1868:1869} > (DF)
23:39:26.671050 64.124.41.179.8888 > 209.179.194.175.1084: P 1847:1868(21) ack 457 win 6432 (DF)
23:39:26.886417 209.179.194.175.1084 > 64.124.41.179.8888: R 371453:371453(0) win 0 (DF)
[-- Attachment #3: win98.log --]
[-- Type: text/plain, Size: 3264 bytes --]
22:34:34.884487 arp who-has 64.124.41.179 tell 209.179.194.175
22:34:34.889477 209.179.194.175.1084 > 64.124.41.179.8888: S 370996:370996(0) win 8192 <mss 536,nop,nop,sackOK> (DF)
22:34:35.669892 64.124.41.179.8888 > 209.179.194.175.1084: S 3050526223:3050526223(0) ack 370997 win 5840 <mss 1460,nop,nop,sackOK> (DF)
22:34:35.670624 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1 win 8576 (DF)
22:34:35.670653 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1 win 65280 (DF)
22:34:35.674484 209.179.194.175.1084 > 64.124.41.179.8888: P 1:44(43) ack 1 win 65280 (DF)
22:34:36.049808 64.124.41.179.8888 > 209.179.194.175.1084: . ack 44 win 5840 (DF)
22:34:36.069773 64.124.41.179.8888 > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF)
22:34:36.069837 64.124.41.179.8888 > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF)
22:34:39.049788 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF)
22:34:39.051638 209.179.194.175.1084 > 64.124.41.179.8888: P 44:56(12) ack 21 win 65260 (DF)
22:34:39.245138 64.124.41.179.8888 > 209.179.194.175.1084: P 21:555(534) ack 44 win 5840 (DF)
22:34:39.245208 64.124.41.179.8888 > 209.179.194.175.1084: P 557:1091(534) ack 56 win 5840 (DF)
22:34:41.739438 209.179.194.175.1084 > 64.124.41.179.8888: P 44:456(412) ack 21 win 65260 (DF)
22:34:42.064811 64.124.41.179.8888 > 209.179.194.175.1084: . ack 456 win 6432 <nop,nop,sack 43360@5 43372@5> (DF)
22:34:45.224789 64.124.41.179.8888 > 209.179.194.175.1084: P 21:557(536) ack 456 win 6432 (DF)
22:34:45.339396 209.179.194.175.1084 > 64.124.41.179.8888: . ack 557 win 65280 (DF)
22:34:45.524819 64.124.41.179.8888 > 209.179.194.175.1084: P 557:1091(534) ack 456 win 6432 (DF)
22:34:45.544830 64.124.41.179.8888 > 209.179.194.175.1084: P 1091:1625(534) ack 456 win 6432 (DF)
22:34:57.508659 64.124.41.179.8888 > 209.179.194.175.1084: P 557:1093(536) ack 456 win 6432 (DF)
22:34:57.664295 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1093 win 65280 (DF)
22:34:57.834842 64.124.41.179.8888 > 209.179.194.175.1084: P 1093:1627(534) ack 456 win 6432 (DF)
22:34:57.854637 64.124.41.179.8888 > 209.179.194.175.1084: P 1627:1843(216) ack 456 win 6432 (DF)
22:35:21.859406 64.124.41.179.8888 > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF)
22:35:21.974090 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1629 win 65280 (DF)
22:35:22.119319 64.124.41.179.8888 > 209.179.194.175.1084: P 1629:1845(216) ack 456 win 6432 (DF)
22:36:10.179021 64.124.41.179.8888 > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF)
22:36:10.323454 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1847 win 65062 (DF)
22:36:10.478939 64.124.41.179.8888 > 209.179.194.175.1084: P 1847:1866(19) ack 456 win 6432 (DF)
22:36:19.818615 209.179.194.175.1084 > 64.124.41.179.8888: F 456:456(0) ack 1847 win 65062 (DF)
22:36:20.003942 [|tcp] (DF)
22:36:20.004076 64.124.41.179.8888 > 209.179.194.175.1084: F 1868:1868(0) ack 457 win 6432 (DF)
22:36:20.008601 209.179.194.175.1084 > 64.124.41.179.8888: . ack 1847 win 65062 <nop,nop,sack 23899@46547 23900@46547> (DF)
22:37:46.513418 64.124.41.179.8888 > 209.179.194.175.1084: P 1847:1868(21) ack 457 win 6432 (DF)
22:37:46.517916 209.179.194.175.1084 > 64.124.41.179.8888: R 371453:371453(0) win 0 (DF)
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:03 ` David S. Miller
2000-11-07 6:44 ` Jordan Mendelson
@ 2000-11-07 6:56 ` David S. Miller
2000-11-07 7:12 ` David S. Miller
` (2 more replies)
2000-11-07 6:59 ` David S. Miller
` (2 subsequent siblings)
4 siblings, 3 replies; 30+ messages in thread
From: David S. Miller @ 2000-11-07 6:56 UTC (permalink / raw)
To: jordy; +Cc: linux-kernel, kuznet
Date: Mon, 06 Nov 2000 22:44:00 -0800
From: Jordan Mendelson <jordy@napster.com>
Attached to this message are dumps from the windows 98 machine using
windump and the linux 2.4.0-test10. Sorry the time stamps don't match
up.
Ok, something is "odd" at the win98 side, I quote the win98 log:
22:34:36.069773 64.124.41.179.8888 > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF)
22:34:36.069837 64.124.41.179.8888 > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF)
Linux sends 1-->553
Since this is in the win98 log, it saw this data, but refuses to
acknowledge it and the retransmit timeout expires on the Linux side.
22:34:39.049788 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF)
So Linux resends 1-->21
22:34:39.051638 209.179.194.175.1084 > 64.124.41.179.8888: P 44:56(12) ack 21 win 65260 (DF)
Win98 sends data, and only acknowledges the resent data from Linux.
22:34:39.245138 64.124.41.179.8888 > 209.179.194.175.1084: P 21:555(534) ack 44 win 5840 (DF)
22:34:39.245208 64.124.41.179.8888 > 209.179.194.175.1084: P 557:1091(534) ack 56 win 5840 (DF)
Win98 machine receives bytes 21-->1091 from Linux, Linux also is
acknowledging Win98's data up to 56, but...
22:34:41.739438 209.179.194.175.1084 > 64.124.41.179.8888: P 44:456(412) ack 21 win 65260 (DF)
Win98 still claims it only saw up to byte 21 from Linux. Win98 also
resends its data, therefore it has not seen Linux's ACKs either.
And this goes on and on.
Just to be absolutely sure, 64.124.41.179 is the Linux machine, right?
If so, Win98 is dropping packets it did in fact receive correctly,
before Win98's TCP has a look at them.
WHOA, wait a second! From the Linux side log:
23:36:16.261533 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF)
23:36:16.261669 64.124.41.179.8888 > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF)
23:36:19.261055 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF)
The equivalent packets from the win98 log:
22:34:36.069773 64.124.41.179.8888 > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF)
22:34:36.069837 64.124.41.179.8888 > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF)
22:34:39.049788 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF)
(ie. Linux sends bytes 1:21 both the first time, and when it
retransmits that data. However win98 "sees" this as 1:19 the first
time and 1:21 during the retransmit by Linux)
That is bogus. Something is mangling the packets between the Linux
machine and the win98 machine. You mentioned something about
bandwidth limiting at your upstream provider, any chance you can have
them turn this bandwidth limiting device off?
Or maybe earthlink is using some packet mangling device?
It is clear though, that something is messing with or corrupting the
packets. One thing you might try is turning off TCP header
compression for the PPP link, does this make a difference?
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:56 ` David S. Miller
@ 2000-11-07 7:12 ` David S. Miller
2000-11-07 7:27 ` David S. Miller
2000-11-07 7:32 ` Jordan Mendelson
2000-11-07 7:16 ` Jordan Mendelson
2000-11-07 9:38 ` Rogier Wolff
2 siblings, 2 replies; 30+ messages in thread
From: David S. Miller @ 2000-11-07 7:12 UTC (permalink / raw)
To: jordy; +Cc: linux-kernel, kuznet
Date: Mon, 06 Nov 2000 23:16:21 -0800
From: Jordan Mendelson <jordy@napster.com>
"David S. Miller" wrote:
> It is clear though, that something is messing with or corrupting the
> packets. One thing you might try is turning off TCP header
> compression for the PPP link, does this make a difference?
Actually, there has been several reports that turning header
compression does help.
If this is what is causing the TCP sequence numbers to change
then either Win98's or Earthlink terminal server's implementation
of TCP header compression is buggy.
Assuming this is true, it explains why Win98's TCP does not "see" the
data sent by Linux, because such a bug would make the TCP checksum of
these packets incorrect and thus dropped by Win98's TCP.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 7:12 ` David S. Miller
@ 2000-11-07 7:27 ` David S. Miller
2000-11-07 9:41 ` Andi Kleen
2000-11-07 9:57 ` David S. Miller
2000-11-07 7:32 ` Jordan Mendelson
1 sibling, 2 replies; 30+ messages in thread
From: David S. Miller @ 2000-11-07 7:27 UTC (permalink / raw)
To: jordy; +Cc: linux-kernel, kuznet
Date: Mon, 06 Nov 2000 23:32:42 -0800
From: Jordan Mendelson <jordy@napster.com>
Ok, but why doesn't 2.2.16 exhibit this behavior?
We've had reports from quite a number of people complaining about
this and I'm fairly certain not all of them are from Earthlink.
The only thing different is that 2.2.x is packetizing the write()
system calls on the server differently, otherwise there is no
difference whatsoever.
What 2.4.x is doing is completely legal. Really, even if not all of
these people are from Earthlink (well, you should see if this is for
certain) they may all be using the same buggy terminal server at these
different ISPs.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 7:27 ` David S. Miller
@ 2000-11-07 9:41 ` Andi Kleen
2000-11-07 9:57 ` David S. Miller
1 sibling, 0 replies; 30+ messages in thread
From: Andi Kleen @ 2000-11-07 9:41 UTC (permalink / raw)
To: David S. Miller; +Cc: jordy, linux-kernel, kuznet
On Mon, Nov 06, 2000 at 11:27:54PM -0800, David S. Miller wrote:
> What 2.4.x is doing is completely legal. Really, even if not all of
> these people are from Earthlink (well, you should see if this is for
> certain) they may all be using the same buggy terminal server at these
> different ISPs.
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)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 7:27 ` David S. Miller
2000-11-07 9:41 ` Andi Kleen
@ 2000-11-07 9:57 ` David S. Miller
1 sibling, 0 replies; 30+ messages in thread
From: David S. Miller @ 2000-11-07 9:57 UTC (permalink / raw)
To: ak; +Cc: jordy, linux-kernel, kuznet
Date: Tue, 7 Nov 2000 10:41:36 +0100
From: Andi Kleen <ak@suse.de>
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)
Sure.
BTW, note the pattern of the win98 logs, basically the whole
connection from the WIN98 side is:
repeat:
LINUX data(N) --> win98 DIFFERENT sequence number
LINUX data(N+1) --> win98 DIFFERENT sequence number
retimeout
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 64.124.41.179.8888 > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF)
22:34:36.069837 64.124.41.179.8888 > 209.179.194.175.1084: 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 64.124.41.179.8888 > 209.179.194.175.1084: P 21:555(534) ack 44 win 5840 (DF)
22:34:39.245208 64.124.41.179.8888 > 209.179.194.175.1084: 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 :-)
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 7:12 ` David S. Miller
2000-11-07 7:27 ` David S. Miller
@ 2000-11-07 7:32 ` Jordan Mendelson
2000-11-07 12:22 ` Alan Cox
1 sibling, 1 reply; 30+ messages in thread
From: Jordan Mendelson @ 2000-11-07 7:32 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, kuznet
"David S. Miller" wrote:
>
> Date: Mon, 06 Nov 2000 23:16:21 -0800
> From: Jordan Mendelson <jordy@napster.com>
>
> "David S. Miller" wrote:
> > It is clear though, that something is messing with or corrupting the
> > packets. One thing you might try is turning off TCP header
> > compression for the PPP link, does this make a difference?
>
> Actually, there has been several reports that turning header
> compression does help.
>
> If this is what is causing the TCP sequence numbers to change
> then either Win98's or Earthlink terminal server's implementation
> of TCP header compression is buggy.
>
> Assuming this is true, it explains why Win98's TCP does not "see" the
> data sent by Linux, because such a bug would make the TCP checksum of
> these packets incorrect and thus dropped by Win98's TCP.
Ok, but why doesn't 2.2.16 exhibit this behavior?
We've had reports from quite a number of people complaining about this
and I'm fairly certain not all of them are from Earthlink.
Jordan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 7:32 ` Jordan Mendelson
@ 2000-11-07 12:22 ` Alan Cox
2000-11-07 12:10 ` David S. Miller
0 siblings, 1 reply; 30+ messages in thread
From: Alan Cox @ 2000-11-07 12:22 UTC (permalink / raw)
To: Jordan Mendelson; +Cc: David S. Miller, linux-kernel, kuznet
> > Assuming this is true, it explains why Win98's TCP does not "see" the
> > data sent by Linux, because such a bug would make the TCP checksum of
> > these packets incorrect and thus dropped by Win98's TCP.
>
> Ok, but why doesn't 2.2.16 exhibit this behavior?
>
> We've had reports from quite a number of people complaining about this
> and I'm fairly certain not all of them are from Earthlink.
If their system is confused by tcp options in data segments then the SACK stuff
in 2.4 may well be the trigger. Windows generally doesnt try and use vj at
all. With the predictable QA results for anyone who does try and use it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 12:22 ` Alan Cox
@ 2000-11-07 12:10 ` David S. Miller
0 siblings, 0 replies; 30+ messages in thread
From: David S. Miller @ 2000-11-07 12:10 UTC (permalink / raw)
To: alan; +Cc: jordy, linux-kernel, kuznet
Date: Tue, 7 Nov 2000 12:22:14 +0000 (GMT)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
If their system is confused by tcp options in data segments then
the SACK stuff in 2.4 may well be the trigger.
SACK is on by default in both the 2.2.x and 2.4.x traces...
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:56 ` David S. Miller
2000-11-07 7:12 ` David S. Miller
@ 2000-11-07 7:16 ` Jordan Mendelson
2000-11-07 9:42 ` Andi Kleen
2000-11-07 9:38 ` Rogier Wolff
2 siblings, 1 reply; 30+ messages in thread
From: Jordan Mendelson @ 2000-11-07 7:16 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel, kuznet
"David S. Miller" wrote:
>
> Date: Mon, 06 Nov 2000 22:44:00 -0800
> From: Jordan Mendelson <jordy@napster.com>
>
> Attached to this message are dumps from the windows 98 machine using
> windump and the linux 2.4.0-test10. Sorry the time stamps don't match
> up.
>
> (ie. Linux sends bytes 1:21 both the first time, and when it
> retransmits that data. However win98 "sees" this as 1:19 the first
> time and 1:21 during the retransmit by Linux)
>
> That is bogus. Something is mangling the packets between the Linux
> machine and the win98 machine. You mentioned something about
> bandwidth limiting at your upstream provider, any chance you can have
> them turn this bandwidth limiting device off?
It actually turns out that that problem with bandwidth was fixed
yesterday, so this can not be the problem here and yes, 64.124.41.179 is
a linux box. :)
> Or maybe earthlink is using some packet mangling device?
>
> It is clear though, that something is messing with or corrupting the
> packets. One thing you might try is turning off TCP header
> compression for the PPP link, does this make a difference?
Actually, there has been several reports that turning header compression
does help.
Jordan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 7:16 ` Jordan Mendelson
@ 2000-11-07 9:42 ` Andi Kleen
2000-11-07 18:13 ` Jordan Mendelson
0 siblings, 1 reply; 30+ messages in thread
From: Andi Kleen @ 2000-11-07 9:42 UTC (permalink / raw)
To: Jordan Mendelson; +Cc: David S. Miller, linux-kernel, kuznet
On Mon, Nov 06, 2000 at 11:16:21PM -0800, Jordan Mendelson wrote:
> > It is clear though, that something is messing with or corrupting the
> > packets. One thing you might try is turning off TCP header
> > compression for the PPP link, does this make a difference?
>
> Actually, there has been several reports that turning header compression
> does help.
What does help ? Turning it on or turning it off ?
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 9:42 ` Andi Kleen
@ 2000-11-07 18:13 ` Jordan Mendelson
0 siblings, 0 replies; 30+ messages in thread
From: Jordan Mendelson @ 2000-11-07 18:13 UTC (permalink / raw)
To: Andi Kleen; +Cc: David S. Miller, linux-kernel, kuznet
Andi Kleen wrote:
>
> On Mon, Nov 06, 2000 at 11:16:21PM -0800, Jordan Mendelson wrote:
> > > It is clear though, that something is messing with or corrupting the
> > > packets. One thing you might try is turning off TCP header
> > > compression for the PPP link, does this make a difference?
> >
> > Actually, there has been several reports that turning header compression
> > does help.
>
> What does help ? Turning it on or turning it off ?
We had a good number of reports that turning PPP header compression off
helped. The windows 98 connection I was testing with it did have header
compression turned on. Unfortunatly, I can't just ask the entire windows
world to turn off header compression in order to use our software. :)
I believe we've reverted all of our machines to 2.2, so testing this any
further is going to be a problem.
Jordan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:56 ` David S. Miller
2000-11-07 7:12 ` David S. Miller
2000-11-07 7:16 ` Jordan Mendelson
@ 2000-11-07 9:38 ` Rogier Wolff
2000-11-07 9:58 ` David S. Miller
2 siblings, 1 reply; 30+ messages in thread
From: Rogier Wolff @ 2000-11-07 9:38 UTC (permalink / raw)
To: David S. Miller; +Cc: jordy, linux-kernel, kuznet
David S. Miller wrote:
> It is clear though, that something is messing with or corrupting the
> packets. One thing you might try is turning off TCP header
> compression for the PPP link, does this make a difference?
Try specifying "asyncmap 0xffffffff" too.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 9:38 ` Rogier Wolff
@ 2000-11-07 9:58 ` David S. Miller
2000-11-07 10:36 ` Rogier Wolff
0 siblings, 1 reply; 30+ messages in thread
From: David S. Miller @ 2000-11-07 9:58 UTC (permalink / raw)
To: R.E.Wolff; +Cc: jordy, linux-kernel, kuznet
Date: Tue, 7 Nov 2000 10:38:12 +0100 (MET)
From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
David S. Miller wrote:
> It is clear though, that something is messing with or corrupting the
> packets. One thing you might try is turning off TCP header
> compression for the PPP link, does this make a difference?
Try specifying "asyncmap 0xffffffff" too.
I wonder how this is specified under win98 :-)
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 9:58 ` David S. Miller
@ 2000-11-07 10:36 ` Rogier Wolff
0 siblings, 0 replies; 30+ messages in thread
From: Rogier Wolff @ 2000-11-07 10:36 UTC (permalink / raw)
To: David S. Miller; +Cc: R.E.Wolff, jordy, linux-kernel, kuznet
David S. Miller wrote:
> Date: Tue, 7 Nov 2000 10:38:12 +0100 (MET)
> From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
>
> David S. Miller wrote:
> > It is clear though, that something is messing with or corrupting the
> > packets. One thing you might try is turning off TCP header
> > compression for the PPP link, does this make a difference?
>
> Try specifying "asyncmap 0xffffffff" too.
>
> I wonder how this is specified under win98 :-)
Well, I missed the initial part of this discussion. From your remark I
must conclude that the Windows box is dialling in to an ISP and it's a
Linux box that is somewhere on the net. Then you can't just put it in
the ppp0.options on the linux box. :-(
I do suspect that there must be a popup screen on W98 that allows you
this control. Possibly it's tucked away in some "registry" entry
somewhere.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:03 ` David S. Miller
2000-11-07 6:44 ` Jordan Mendelson
2000-11-07 6:56 ` David S. Miller
@ 2000-11-07 6:59 ` David S. Miller
2000-11-07 7:14 ` David S. Miller
2000-11-07 7:16 ` Andi Kleen
2000-11-07 7:03 ` Andi Kleen
2000-11-07 22:43 ` Lincoln Dale
4 siblings, 2 replies; 30+ messages in thread
From: David S. Miller @ 2000-11-07 6:59 UTC (permalink / raw)
To: ak; +Cc: jordy, linux-kernel, kuznet
Date: Tue, 7 Nov 2000 08:03:42 +0100
From: Andi Kleen <ak@suse.de>
It looks very like to me like a poster child for the non timestamp
RTT update problem I just described on netdev. Linux always
retransmits too early and there is never a better RTT estimate
which could fix it.
I thought so too, _BUT_ see my analysis of the Linux side vs.
Win98 side logs, they don't match up and therefore something
is mangling the packets in the middle. The TCP sequence numbers are
being changed!
Also, if your theory were true then 2.2.x would be affected
by it as well.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:59 ` David S. Miller
@ 2000-11-07 7:14 ` David S. Miller
2000-11-07 7:16 ` Andi Kleen
1 sibling, 0 replies; 30+ messages in thread
From: David S. Miller @ 2000-11-07 7:14 UTC (permalink / raw)
To: ak; +Cc: jordy, linux-kernel, kuznet
Date: Tue, 7 Nov 2000 08:16:04 +0100
From: Andi Kleen <ak@suse.de>
Hmm. One of these weird bandwidth limiters again?
In a more recent mail, TCP header compression in Win98 or Earthlink's
terminal servers have become the current prime suspect. :-)
The RTT is lower than 2.2's initial 3s RTT, so 2.2 would never see
it.
The 240 traces are using an RTT of 3s (look at the time difference of
the first retransmit), so this is not it.
Later,
David S. Miller
davem@redhat.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:59 ` David S. Miller
2000-11-07 7:14 ` David S. Miller
@ 2000-11-07 7:16 ` Andi Kleen
1 sibling, 0 replies; 30+ messages in thread
From: Andi Kleen @ 2000-11-07 7:16 UTC (permalink / raw)
To: David S. Miller; +Cc: ak, jordy, linux-kernel, kuznet
On Mon, Nov 06, 2000 at 10:59:04PM -0800, David S. Miller wrote:
> Date: Tue, 7 Nov 2000 08:03:42 +0100
> From: Andi Kleen <ak@suse.de>
>
> It looks very like to me like a poster child for the non timestamp
> RTT update problem I just described on netdev. Linux always
> retransmits too early and there is never a better RTT estimate
> which could fix it.
>
> I thought so too, _BUT_ see my analysis of the Linux side vs.
> Win98 side logs, they don't match up and therefore something
> is mangling the packets in the middle. The TCP sequence numbers are
> being changed!
Hmm. One of these weird bandwidth limiters again?
>
> Also, if your theory were true then 2.2.x would be affected
> by it as well.
2.2 does not save RTTs between connections. The RTT is lower than 2.2's
initial 3s RTT, so 2.2 would never see it. One useful experiment would
be to flush the routing cache between attempts or turn off the tcp metrics
saving (why don't we have a sysctl for that btw?)
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:03 ` David S. Miller
` (2 preceding siblings ...)
2000-11-07 6:59 ` David S. Miller
@ 2000-11-07 7:03 ` Andi Kleen
2000-11-07 22:43 ` Lincoln Dale
4 siblings, 0 replies; 30+ messages in thread
From: Andi Kleen @ 2000-11-07 7:03 UTC (permalink / raw)
To: David S. Miller; +Cc: jordy, linux-kernel, kuznet
On Mon, Nov 06, 2000 at 10:03:05PM -0800, David S. Miller wrote:
> The only thing I can do now is beg for a tcpdump from the windows95
> machine side. Do you have the facilities necessary to obtain this?
> This would prove that it is packet drop between the two systems, for
> whatever reason, that is causing this.
It looks very like to me like a poster child for the non timestamp
RTT update problem I just described on netdev. Linux always retransmits
too early and there is never a better RTT estimate which could fix it.
2.4's advertised windows also do not seem to cope with weird window
advertising strategy of windows (start with a small window and then
suddenly increase it). Linux's stays small.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
2000-11-07 6:03 ` David S. Miller
` (3 preceding siblings ...)
2000-11-07 7:03 ` Andi Kleen
@ 2000-11-07 22:43 ` Lincoln Dale
4 siblings, 0 replies; 30+ messages in thread
From: Lincoln Dale @ 2000-11-07 22:43 UTC (permalink / raw)
To: David S. Miller; +Cc: jordy, linux-kernel, kuznet
>23:36:16.261533 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack
>44 win 5840 (DF)
>23:36:16.261669 64.124.41.179.8888 > 209.179.194.175.1084: P 21:557(536)
>ack 44 win 5840 (DF)
>23:36:19.261055 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack
>44 win 5840 (DF)
>
>The equivalent packets from the win98 log:
>
>22:34:36.069773 64.124.41.179.8888 > 209.179.194.175.1084: P 1:19(18) ack
>44 win 5840 (DF)
>22:34:36.069837 64.124.41.179.8888 > 209.179.194.175.1084: P 19:553(534)
>ack 44 win 5840 (DF)
>22:34:39.049788 64.124.41.179.8888 > 209.179.194.175.1084: P 1:21(20) ack
>44 win 5840 (DF)
>
>(ie. Linux sends bytes 1:21 both the first time, and when it
> retransmits that data. However win98 "sees" this as 1:19 the first
> time and 1:21 during the retransmit by Linux)
this excerpt looks like when a modem is set to eat XON/XOFF ...
a ping which does a sweep of many byte values should show this up ...
cheers,
lincoln.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 30+ messages in thread