Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
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 0x" too. Roger. -- ** [EMAIL PROTECTED] ** 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
David S. Miller wrote: > Linux resends 21:557, Windows95 (finally) acknowledges it. > > Looking at the equivalent 220 traces, the only difference appears to > be that the packets are not getting dropped. This smells of "wrong checksums getting generated", in my opinion. (This is not my field of expertise. I'll keep my trap shut from now on, OK?) Roger. -- ** [EMAIL PROTECTED] ** 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
David S. Miller wrote: Linux resends 21:557, Windows95 (finally) acknowledges it. Looking at the equivalent 220 traces, the only difference appears to be that the packets are not getting dropped. This smells of "wrong checksums getting generated", in my opinion. (This is not my field of expertise. I'll keep my trap shut from now on, OK?) Roger. -- ** [EMAIL PROTECTED] ** 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
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 0x" too. Roger. -- ** [EMAIL PROTECTED] ** 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 23:32:42 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date: Mon, 06 Nov 2000 23:16:21 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >"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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Tue, 7 Nov 2000 08:16:04 +0100 From: Andi Kleen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 23:16:21 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> "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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date: Mon, 06 Nov 2000 22:44:00 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
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 <[EMAIL PROTECTED]> > >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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Tue, 7 Nov 2000 08:03:42 +0100 From: Andi Kleen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 22:44:00 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> 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. > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF) 22:34:36.069837 64.124.41.179. > 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. > 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.: 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. > 209.179.194.175.1084: P 21:555(534) ack 44 win 5840 (DF) 22:34:39.245208 64.124.41.179. > 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.: 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. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) 23:36:16.261669 64.124.41.179. > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF) 23:36:19.261055 64.124.41.179. > 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. > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF) 22:34:36.069837 64.124.41.179. > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF) 22:34:39.049788 64.124.41.179. > 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date: Mon, 06 Nov 2000 22:13:23 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >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 23:36:15.252817 209.179.194.175.1084 > 64.124.41.179.: S 370996:370996(0) win 8192 (DF) 23:36:15.252891 64.124.41.179. > 209.179.194.175.1084: S 3050526223:3050526223(0) ack 370997 win 5840 (DF) 23:36:16.159685 209.179.194.175.1084 > 64.124.41.179.: . ack 1 win 8576 (DF) 23:36:16.160461 209.179.194.175.1084 > 64.124.41.179.: . ack 1 win 65280 (DF) 23:36:16.160488 209.179.194.175.1084 > 64.124.41.179.: P 1:44(43) ack 1 win 65280 (DF) 23:36:16.160506 64.124.41.179. > 209.179.194.175.1084: . ack 44 win 5840 (DF) 23:36:16.261533 64.124.41.179. > 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) 23:36:16.261669 64.124.41.179. > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF) 23:36:19.261055 64.124.41.179. > 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.: P 44:56(12) ack 21 win 65260 (DF) 23:36:19.450788 64.124.41.179. > 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF) 23:36:19.450820 64.124.41.179. > 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.: P 44:456(412) ack 21 win 65260 (DF) 23:36:22.281308 64.124.41.179. > 209.179.194.175.1084: . ack 456 win 6432 (DF) 23:36:25.441061 64.124.41.179. > 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.: . ack 557 win 65280 (DF) 23:36:25.701841 64.124.41.179. > 209.179.194.175.1084: P 557:1093(536) ack 456 win 6432 (DF) 23:36:25.701859 64.124.41.179. > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF) 23:36:37.701091 64.124.41.179. > 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.: . ack 1093 win 65280 (DF) 23:36:38.026826 64.124.41.179. > 209.179.194.175.1084: P 1093:1629(536) ack 456 win 6432 (DF) 23:36:38.026839 64.124.41.179. > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF) 23:37:02.021068 64.124.41.179. > 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.: . ack 1629 win 65280 (DF) 23:37:02.328189 64.124.41.179. > 209.179.194.175.1084: P 1629:1847(218) ack 456 win 6432 (DF) 23:37:50.321057 64.124.41.179. > 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.: . ack 1847 win 65062 (DF) 23:37:50.673068 64.124.41.179. > 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.: F 456:456(0) ack 1847 win 65062 (DF) 23:38:00.181055 64.124.41.179. > 209.179.194.175.1084: . ack 457 win 6432 (DF) 23:38:00.187291 64.124.41.179. > 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.: . ack 1847 win 65062 (DF) 23:39:26.671050 64.124.41.179. > 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.: R 371453:371453(0) win 0 (DF) 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.: S 370996:370996(0) win 8192 (DF) 22:34:35.669892 64.124.41.179. > 209.179.194.175.1084: S 3050526223:3050526223(0) ack 370997 win 5840 (DF) 22:34:35.670624 209.179.194.175.1084 > 64.124.41.179.: . ack 1 win 8576 (DF) 22:34:35.670653 209.179.194.175.1084 > 64.124.41.179.: . ack 1 win 65280 (DF) 22:34:35.674484 209.179.194.175.1084 > 64.124.41.179.: P 1:44(43) ack 1 win 65280 (DF) 22:34:36.049808 64.124.41.179. > 209.179.194.175.1084: . ack 44 win 5840 (DF) 22:34:36.069773 64.124.41.179. > 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF) 22:34:36.069837 64.124.41.179. > 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF) 22:34:39.049788 64.124.41.179. > 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.: P 44:56(12) ack 21 win 65260 (DF)
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 22:13:23 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> 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. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date: Mon, 06 Nov 2000 21:20:39 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >It looks to me like there is an artificial delay in 2.4.0 which is >slowing down the traffic to unbearable levels. > > No, I think I see whats wrong, it's nothing more than packet drop. > > Looking at the equivalent 220 traces, the only difference appears to > be that the packets are not getting dropped. I would like to note that these two machines the windows client is connecting to are sitting on the exact same switch connected to the same provider handling identical user loads. > Alexey, do you have any other similar reports wrt. the new MSS > advertisement scheme in 2.4.x? > > Jordan, you mentioned something about possibly being "bandwidth > limited"? Please, elaborate... 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. Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 21:20:39 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> It looks to me like there is an artificial delay in 2.4.0 which is slowing down the traffic to unbearable levels. No, I think I see whats wrong, it's nothing more than packet drop. The large gaps in time seem to be due to packets being dropped: 22:00:39.991515 64.124.41.179. > 209.179.245.186.1092: P 1:21(20) ack 44 win 5840 (DF) 22:00:39.991660 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 44 win 5840 (DF) 3 seconds pass, retransmit time out. 22:00:42.991490 64.124.41.179. > 209.179.245.186.1092: P 1:21(20) ack 44 win 5840 (DF) Linux retransmits dropped data. 22:00:43.180946 209.179.245.186.1092 > 64.124.41.179.: P 44:56(12) ack 21 win 65260 (DF) Windows95 responds, acknowledges up to byte 21. 22:00:43.180997 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 44 win 5840 (DF) 22:00:43.181025 64.124.41.179. > 209.179.245.186.1092: P 557:1093(536) ack 56 win 5840 (DF) 22:00:45.685143 209.179.245.186.1092 > 64.124.41.179.: P 44:456(412) ack 21 win 65260 (DF) Linux resends bytes 21:556 and sends new data from 557:1093. Windows95 sends new data and ACKs only up to 21 (meaning presumably that all bytes sent by Linux this time were dropped). 22:00:45.685204 64.124.41.179. > 209.179.245.186.1092: . ack 456 win 6432 (DF) Linux acknowledges data received from Windows95 machine. A retransmit timeout occurs on the lost data. 22:00:49.171046 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 456 win 6432 (DF) 22:00:49.470193 209.179.245.186.1092 > 64.124.41.179.: . ack 557 win 65280 (DF) Linux resends 21:557, Windows95 (finally) acknowledges it. Looking at the equivalent 220 traces, the only difference appears to be that the packets are not getting dropped. Alexey, do you have any other similar reports wrt. the new MSS advertisement scheme in 2.4.x? Jordan, you mentioned something about possibly being "bandwidth limited"? Please, elaborate... Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
"David S. Miller" wrote: > >Date:Mon, 06 Nov 2000 18:17:19 -0800 >From: Jordan Mendelson <[EMAIL PROTECTED]> > >18:54:57.394894 eth0 > 64.124.41.177. > 209.179.248.69.1238: . >2429:2429(0) ack 506 win 6432 (DF) > > And this is it? The connection dies right here and says no > more? Surely, there was more said on this connection after > this point. > > Otherwise I see nothing obviously wrong in these dumps. I've provided two new dumps of the complete connection lifetime between 2.4.0 and 2.2.16. Both logs show the same client connecting to identical machines, receiving the same data and then disconnecting. 2.2.16 handles the entire process in under 5 seconds while 2.4.0 takes over 2 minutes. Also note that the 2.4.0 connection did not get shut down correctly and had to send an RST... though this is probably due to the client side closing down the connection while there was still data on it. Both machines were under approximately the same load. It looks to me like there is an artificial delay in 2.4.0 which is slowing down the traffic to unbearable levels. Jordan 22:00:39.625351 209.179.245.186.1092 > 64.124.41.179.: S 4155530:4155530(0) win 8192 (DF) 22:00:39.625437 64.124.41.179. > 209.179.245.186.1092: S 1301092473:1301092473(0) ack 4155531 win 5840 (DF) 22:00:39.887133 209.179.245.186.1092 > 64.124.41.179.: . ack 1 win 8576 (DF) 22:00:39.887969 209.179.245.186.1092 > 64.124.41.179.: . ack 1 win 65280 (DF) 22:00:39.888951 209.179.245.186.1092 > 64.124.41.179.: P 1:44(43) ack 1 win 65280 (DF) 22:00:39.888964 64.124.41.179. > 209.179.245.186.1092: . ack 44 win 5840 (DF) 22:00:39.991515 64.124.41.179. > 209.179.245.186.1092: P 1:21(20) ack 44 win 5840 (DF) 22:00:39.991660 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 44 win 5840 (DF) 22:00:42.991490 64.124.41.179. > 209.179.245.186.1092: P 1:21(20) ack 44 win 5840 (DF) 22:00:43.180946 209.179.245.186.1092 > 64.124.41.179.: P 44:56(12) ack 21 win 65260 (DF) 22:00:43.180997 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 44 win 5840 (DF) 22:00:43.181025 64.124.41.179. > 209.179.245.186.1092: P 557:1093(536) ack 56 win 5840 (DF) 22:00:45.685143 209.179.245.186.1092 > 64.124.41.179.: P 44:456(412) ack 21 win 65260 (DF) 22:00:45.685204 64.124.41.179. > 209.179.245.186.1092: . ack 456 win 6432 (DF) 22:00:49.171046 64.124.41.179. > 209.179.245.186.1092: P 21:557(536) ack 456 win 6432 (DF) 22:00:49.470193 209.179.245.186.1092 > 64.124.41.179.: . ack 557 win 65280 (DF) 22:00:49.470233 64.124.41.179. > 209.179.245.186.1092: P 557:1093(536) ack 456 win 6432 (DF) 22:00:49.470248 64.124.41.179. > 209.179.245.186.1092: P 1093:1629(536) ack 456 win 6432 (DF) 22:01:01.461056 64.124.41.179. > 209.179.245.186.1092: P 557:1093(536) ack 456 win 6432 (DF) 22:01:01.755362 209.179.245.186.1092 > 64.124.41.179.: . ack 1093 win 65280 (DF) 22:01:01.755428 64.124.41.179. > 209.179.245.186.1092: P 1093:1629(536) ack 456 win 6432 (DF) 22:01:01.755451 64.124.41.179. > 209.179.245.186.1092: P 1629:1825(196) ack 456 win 6432 (DF) 22:01:25.751048 64.124.41.179. > 209.179.245.186.1092: P 1093:1629(536) ack 456 win 6432 (DF) 22:01:26.171932 209.179.245.186.1092 > 64.124.41.179.: . ack 1629 win 65280 (DF) 22:01:26.171979 64.124.41.179. > 209.179.245.186.1092: P 1629:1825(196) ack 456 win 6432 (DF) 22:02:14.171052 64.124.41.179. > 209.179.245.186.1092: P 1629:1825(196) ack 456 win 6432 (DF) 22:02:14.499920 209.179.245.186.1092 > 64.124.41.179.: . ack 1825 win 65084 (DF) 22:02:14.499944 64.124.41.179. > 209.179.245.186.1092: P 1825:1847(22) ack 456 win 6432 (DF) 22:02:16.168708 209.179.245.186.1092 > 64.124.41.179.: F 456:456(0) ack 1825 win 65084 (DF) 22:02:16.181061 64.124.41.179. > 209.179.245.186.1092: . ack 457 win 6432 (DF) 22:02:16.281724 64.124.41.179. > 209.179.245.186.1092: F 1847:1847(0) ack 457 win 6432 (DF) 22:02:16.477943 209.179.245.186.1092 > 64.124.41.179.: . ack 1825 win 65084 (DF) 22:03:50.491063 64.124.41.179. > 209.179.245.186.1092: P 1825:1847(22) ack 457 win 6432 (DF) 22:03:50.680141 209.179.245.186.1092 > 64.124.41.179.: R 4155987:4155987(0) win 0 (DF) 22:00:01.684927 209.179.245.186.1091 > 64.124.41.136.: S 4033171:4033171(0) win 8192 (DF) 22:00:01.685021 64.124.41.136. > 209.179.245.186.1091: S 1261602556:1261602556(0) ack 4033172 win 32696 (DF) 22:00:01.916120 209.179.245.186.1091 > 64.124.41.136.: . ack 1 win 8576 (DF) 22:00:01.916191 209.179.245.186.1091 > 64.124.41.136.: . ack 1 win 65280 (DF) 22:00:01.916981 209.179.245.186.1091 > 64.124.41.136.: P 1:44(43) ack 1 win 65280 (DF) 22:00:01.917032 64.124.41.136. > 209.179.245.186.1091: . ack 44 win 32696 (DF) 22:00:02.121143 64.124.41.136. > 209.179.245.186.1091: P 1:21(20) ack 44 win 32696 (DF) 22:00:02.121279 64.124.41.136. > 209.179.245.186.1091: P
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date: Mon, 06 Nov 2000 19:44:57 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> Just some updates. This problem does not appear to happen under 2.2.16. The dump for 2.2.16 is almost the same except we send an mss back of 536 and not 1460 (remote mtu vs local mtu). MSS advertized makes no difference, it controls not what sized payloads we send, which is determined in this case by PMTU and thus both Linux 2.2.x and 2.4.x send equally sized limited packets. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Date:Mon, 06 Nov 2000 18:17:19 -0800 From: Jordan Mendelson <[EMAIL PROTECTED]> 18:54:57.394894 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 2429:2429(0) ack 506 win 6432 (DF) And this is it? The connection dies right here and says no more? Surely, there was more said on this connection after this point. Otherwise I see nothing obviously wrong in these dumps. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
Jordan Mendelson wrote: > > We are seeing a performance slowdown between Windows PPP users and > servers running 2.4.0-test10. Attached is a tcpdump log of the > connection. The machines is without TCP ECN support. The Windows machine > is running Windows 98 SE 4.10. A dialed up over PPP w/ TCP header > compression. The Linux machine is connected directly to the Internet via > a 6509. There is a possibility that we are hitting a bandwidth cap on > outgoing traffic. Just some updates. This problem does not appear to happen under 2.2.16. The dump for 2.2.16 is almost the same except we send an mss back of 536 and not 1460 (remote mtu vs local mtu). Here is the head of a tcpdump with the same client, but this time with a 2.2.16 machine instead of a 2.4.0-test10 machine: 19:26:23.593114 eth0 < 209.179.248.69.1260 > 64.124.41.136.: S 5061245:5061245(0) win 8192 (DF) 19:26:23.593237 eth0 > 64.124.41.136. > 209.179.248.69.1260: S 119520695:119520695(0) ack 5061246 win 32696 (DF) 19:26:23.824394 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 1:1(0) ack 1 win 65280 (DF) 19:26:23.824398 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 1:1(0) ack 1 win 8576 (DF) 19:26:23.825249 eth0 < 209.179.248.69.1260 > 64.124.41.136.: P 1:44(43) ack 1 win 65280 (DF) 19:26:23.825283 eth0 > 64.124.41.136. > 209.179.248.69.1260: . 1:1(0) ack 44 win 32696 (DF) 19:26:25.245845 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 1:21(20) ack 44 win 32696 (DF) 19:26:25.245956 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 21:342(321) ack 44 win 32696 (DF) 19:26:25.466759 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 44:44(0) ack 342 win 64939 (DF) 19:26:25.466792 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 342:878(536) ack 44 win 32696 (DF) 19:26:25.466800 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 878:1401(523) ack 44 win 32696 (DF) 19:26:25.467562 eth0 < 209.179.248.69.1260 > 64.124.41.136.: P 44:56(12) ack 342 win 64939 (DF) 19:26:25.480104 eth0 > 64.124.41.136. > 209.179.248.69.1260: . 1401:1401(0) ack 56 win 32696 (DF) 19:26:25.763509 eth0 < 209.179.248.69.1260 > 64.124.41.136.: P 56:456(400) ack 878 win 65280 (DF) 19:26:25.766253 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 456:456(0) ack 1401 win 64757 (DF) 19:26:26.070115 eth0 > 64.124.41.136. > 209.179.248.69.1260: . 1401:1401(0) ack 456 win 32296 (DF) 19:26:26.431515 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 1401:1413(12) ack 456 win 32696 (DF) 19:26:26.432141 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 1413:1684(271) ack 456 win 32696 (DF) 19:26:26.657631 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 456:456(0) ack 1684 win 65280 (DF) 19:26:26.657663 eth0 > 64.124.41.136. > 209.179.248.69.1260: P 1684:1817(133) ack 456 win 32696 (DF) 19:26:26.952825 eth0 < 209.179.248.69.1260 > 64.124.41.136.: . 456:456(0) ack 1817 win 65147 (DF) 19:26:31.086138 eth0 < 209.179.248.69.1260 > 64.124.41.136.: P 456:506(50) ack 1817 win 65147 (DF) > 18:51:33.282286 eth0 < 209.179.248.69.1238 > 64.124.41.177.: S > 3013389:3013389(0) win 8192 (DF) > 18:51:33.282395 eth0 > 64.124.41.177. > 209.179.248.69.1238: S > 2198113890:2198113890(0) ack 3013390 win 5840 > (DF) > 18:51:33.509532 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . > 1:1(0) ack 1 win 8576 (DF) > 18:51:33.510360 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . > 1:1(0) ack 1 win 65280 (DF) > 18:51:33.510416 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P > 1:44(43) ack 1 win 65280 (DF) > 18:51:33.510457 eth0 > 64.124.41.177. > 209.179.248.69.1238: . > 1:1(0) ack 44 win 5840 (DF) > 18:51:33.988330 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 1:21(20) ack 44 win 5840 (DF) > 18:51:33.988474 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 21:557(536) ack 44 win 5840 (DF) > 18:51:36.987336 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 1:21(20) ack 44 win 5840 (DF) > 18:51:37.12 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P > 44:56(12) ack 21 win 65260 (DF) > 18:51:37.177794 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 21:557(536) ack 44 win 5840 (DF) > 18:51:37.177806 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 557:1093(536) ack 56 win 5840 (DF) > 18:51:39.845046 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P > 44:456(412) ack 21 win 65260 (DF) > 18:51:39.845071 eth0 > 64.124.41.177. > 209.179.248.69.1238: . > 1093:1093(0) ack 456 win 6432 (DF) > 18:51:43.177329 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 21:557(536) ack 456 win 6432 (DF) > 18:51:43.538219 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . > 456:456(0) ack 557 win 65280 (DF) > 18:51:43.538275 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 557:1093(536) ack 456 win 6432 (DF) > 18:51:43.538292 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 1093:1629(536) ack 456 win 6432 (DF) > 18:51:55.537346 eth0 > 64.124.41.177. > 209.179.248.69.1238: P > 557:1093(536) ack 456
Poor TCP Performance 2.4.0-10 <-> Win98 SE PPP
We are seeing a performance slowdown between Windows PPP users and servers running 2.4.0-test10. Attached is a tcpdump log of the connection. The machines is without TCP ECN support. The Windows machine is running Windows 98 SE 4.10. A dialed up over PPP w/ TCP header compression. The Linux machine is connected directly to the Internet via a 6509. There is a possibility that we are hitting a bandwidth cap on outgoing traffic. 18:51:33.282286 eth0 < 209.179.248.69.1238 > 64.124.41.177.: S 3013389:3013389(0) win 8192 (DF) 18:51:33.282395 eth0 > 64.124.41.177. > 209.179.248.69.1238: S 2198113890:2198113890(0) ack 3013390 win 5840 (DF) 18:51:33.509532 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 1:1(0) ack 1 win 8576 (DF) 18:51:33.510360 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 1:1(0) ack 1 win 65280 (DF) 18:51:33.510416 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 1:44(43) ack 1 win 65280 (DF) 18:51:33.510457 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 1:1(0) ack 44 win 5840 (DF) 18:51:33.988330 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1:21(20) ack 44 win 5840 (DF) 18:51:33.988474 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 21:557(536) ack 44 win 5840 (DF) 18:51:36.987336 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1:21(20) ack 44 win 5840 (DF) 18:51:37.12 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 44:56(12) ack 21 win 65260 (DF) 18:51:37.177794 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 21:557(536) ack 44 win 5840 (DF) 18:51:37.177806 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 557:1093(536) ack 56 win 5840 (DF) 18:51:39.845046 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 44:456(412) ack 21 win 65260 (DF) 18:51:39.845071 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 1093:1093(0) ack 456 win 6432 (DF) 18:51:43.177329 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 21:557(536) ack 456 win 6432 (DF) 18:51:43.538219 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 557 win 65280 (DF) 18:51:43.538275 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 557:1093(536) ack 456 win 6432 (DF) 18:51:43.538292 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1093:1629(536) ack 456 win 6432 (DF) 18:51:55.537346 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 557:1093(536) ack 456 win 6432 (DF) 18:51:55.841360 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 1093 win 65280 (DF) 18:51:55.841384 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1093:1629(536) ack 456 win 6432 (DF) 18:51:55.841393 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1629:1849(220) ack 456 win 6432 (DF) 18:52:19.837335 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1093:1629(536) ack 456 win 6432 (DF) 18:52:20.153776 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 1629 win 65280 (DF) 18:52:20.153803 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1629:1849(220) ack 456 win 6432 (DF) 18:53:08.147334 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1629:1849(220) ack 456 win 6432 (DF) 18:53:08.475911 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 1849 win 65060 (DF) 18:53:08.475947 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1849:1871(22) ack 456 win 6432 (DF) 18:54:44.467332 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1849:1871(22) ack 456 win 6432 (DF) 18:54:44.824187 eth0 < 209.179.248.69.1238 > 64.124.41.177.: . 456:456(0) ack 1871 win 65038 (DF) 18:54:44.824256 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1871:1893(22) ack 456 win 6432 (DF) 18:54:55.212750 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 456:506(50) ack 1871 win 65038 (DF) 18:54:55.212767 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 1893:1893(0) ack 506 win 6432 (DF) 18:54:55.571337 eth0 > 64.124.41.177. > 209.179.248.69.1238: P 1893:2429(536) ack 506 win 6432 (DF) 18:54:57.394879 eth0 < 209.179.248.69.1238 > 64.124.41.177.: P 456:506(50) ack 1871 win 65038 (DF) 18:54:57.394894 eth0 > 64.124.41.177. > 209.179.248.69.1238: . 2429:2429(0) ack 506 win 6432 (DF) Here are some numbers from /proc/sys/net/ipv4: $ cat /proc/sys/net/ipv4/tcp_rmem 409687380 174760 $ cat /proc/sys/net/ipv4/tcp_wmem 409616384 131072 $ cat /proc/sys/net/ipv4/tcp_sack 1 $ cat /proc/sys/net/ipv4/tcp_fack 1 $ cat /proc/sys/net/ipv4/tcp_dsack 1 $ cat /proc/sys/net/ipv4/tcp_window_scaling 1 $ cat /proc/sys/net/ipv4/tcp_syncookies 0 $ cat /proc/sys/net/ipv4/tcp_timestamps 1 Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Date:Mon, 06 Nov 2000 18:17:19 -0800
From: Jordan Mendelson [EMAIL PROTECTED]
18:54:57.394894 eth0 64.124.41.177. 209.179.248.69.1238: .
2429:2429(0) ack 506 win 6432 nop,nop, sack 1 {456:506} (DF)
And this is it? The connection dies right here and says no
more? Surely, there was more said on this connection after
this point.
Otherwise I see nothing obviously wrong in these dumps.
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Date: Mon, 06 Nov 2000 19:44:57 -0800 From: Jordan Mendelson [EMAIL PROTECTED] Just some updates. This problem does not appear to happen under 2.2.16. The dump for 2.2.16 is almost the same except we send an mss back of 536 and not 1460 (remote mtu vs local mtu). MSS advertized makes no difference, it controls not what sized payloads we send, which is determined in this case by PMTU and thus both Linux 2.2.x and 2.4.x send equally sized limited packets. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Jordan Mendelson wrote:
We are seeing a performance slowdown between Windows PPP users and
servers running 2.4.0-test10. Attached is a tcpdump log of the
connection. The machines is without TCP ECN support. The Windows machine
is running Windows 98 SE 4.10. A dialed up over PPP w/ TCP header
compression. The Linux machine is connected directly to the Internet via
a 6509. There is a possibility that we are hitting a bandwidth cap on
outgoing traffic.
Just some updates. This problem does not appear to happen under 2.2.16.
The dump for 2.2.16 is almost the same except we send an mss back of 536
and not 1460 (remote mtu vs local mtu).
Here is the head of a tcpdump with the same client, but this time with a
2.2.16 machine instead of a 2.4.0-test10 machine:
19:26:23.593114 eth0 209.179.248.69.1260 64.124.41.136.: S
5061245:5061245(0) win 8192 mss 536,nop,nop,sackOK (DF)
19:26:23.593237 eth0 64.124.41.136. 209.179.248.69.1260: S
119520695:119520695(0) ack 5061246 win 32696 mss 536,nop,nop,sackOK
(DF)
19:26:23.824394 eth0 209.179.248.69.1260 64.124.41.136.: .
1:1(0) ack 1 win 65280 (DF)
19:26:23.824398 eth0 209.179.248.69.1260 64.124.41.136.: .
1:1(0) ack 1 win 8576 (DF)
19:26:23.825249 eth0 209.179.248.69.1260 64.124.41.136.: P
1:44(43) ack 1 win 65280 (DF)
19:26:23.825283 eth0 64.124.41.136. 209.179.248.69.1260: .
1:1(0) ack 44 win 32696 (DF)
19:26:25.245845 eth0 64.124.41.136. 209.179.248.69.1260: P
1:21(20) ack 44 win 32696 (DF)
19:26:25.245956 eth0 64.124.41.136. 209.179.248.69.1260: P
21:342(321) ack 44 win 32696 (DF)
19:26:25.466759 eth0 209.179.248.69.1260 64.124.41.136.: .
44:44(0) ack 342 win 64939 (DF)
19:26:25.466792 eth0 64.124.41.136. 209.179.248.69.1260: P
342:878(536) ack 44 win 32696 (DF)
19:26:25.466800 eth0 64.124.41.136. 209.179.248.69.1260: P
878:1401(523) ack 44 win 32696 (DF)
19:26:25.467562 eth0 209.179.248.69.1260 64.124.41.136.: P
44:56(12) ack 342 win 64939 (DF)
19:26:25.480104 eth0 64.124.41.136. 209.179.248.69.1260: .
1401:1401(0) ack 56 win 32696 (DF)
19:26:25.763509 eth0 209.179.248.69.1260 64.124.41.136.: P
56:456(400) ack 878 win 65280 (DF)
19:26:25.766253 eth0 209.179.248.69.1260 64.124.41.136.: .
456:456(0) ack 1401 win 64757 (DF)
19:26:26.070115 eth0 64.124.41.136. 209.179.248.69.1260: .
1401:1401(0) ack 456 win 32296 (DF)
19:26:26.431515 eth0 64.124.41.136. 209.179.248.69.1260: P
1401:1413(12) ack 456 win 32696 (DF)
19:26:26.432141 eth0 64.124.41.136. 209.179.248.69.1260: P
1413:1684(271) ack 456 win 32696 (DF)
19:26:26.657631 eth0 209.179.248.69.1260 64.124.41.136.: .
456:456(0) ack 1684 win 65280 (DF)
19:26:26.657663 eth0 64.124.41.136. 209.179.248.69.1260: P
1684:1817(133) ack 456 win 32696 (DF)
19:26:26.952825 eth0 209.179.248.69.1260 64.124.41.136.: .
456:456(0) ack 1817 win 65147 (DF)
19:26:31.086138 eth0 209.179.248.69.1260 64.124.41.136.: P
456:506(50) ack 1817 win 65147 (DF)
18:51:33.282286 eth0 209.179.248.69.1238 64.124.41.177.: S
3013389:3013389(0) win 8192 mss 536,nop,nop,sackOK (DF)
18:51:33.282395 eth0 64.124.41.177. 209.179.248.69.1238: S
2198113890:2198113890(0) ack 3013390 win 5840 mss 1460,nop,nop,sackOK
(DF)
18:51:33.509532 eth0 209.179.248.69.1238 64.124.41.177.: .
1:1(0) ack 1 win 8576 (DF)
18:51:33.510360 eth0 209.179.248.69.1238 64.124.41.177.: .
1:1(0) ack 1 win 65280 (DF)
18:51:33.510416 eth0 209.179.248.69.1238 64.124.41.177.: P
1:44(43) ack 1 win 65280 (DF)
18:51:33.510457 eth0 64.124.41.177. 209.179.248.69.1238: .
1:1(0) ack 44 win 5840 (DF)
18:51:33.988330 eth0 64.124.41.177. 209.179.248.69.1238: P
1:21(20) ack 44 win 5840 (DF)
18:51:33.988474 eth0 64.124.41.177. 209.179.248.69.1238: P
21:557(536) ack 44 win 5840 (DF)
18:51:36.987336 eth0 64.124.41.177. 209.179.248.69.1238: P
1:21(20) ack 44 win 5840 (DF)
18:51:37.12 eth0 209.179.248.69.1238 64.124.41.177.: P
44:56(12) ack 21 win 65260 (DF)
18:51:37.177794 eth0 64.124.41.177. 209.179.248.69.1238: P
21:557(536) ack 44 win 5840 (DF)
18:51:37.177806 eth0 64.124.41.177. 209.179.248.69.1238: P
557:1093(536) ack 56 win 5840 (DF)
18:51:39.845046 eth0 209.179.248.69.1238 64.124.41.177.: P
44:456(412) ack 21 win 65260 (DF)
18:51:39.845071 eth0 64.124.41.177. 209.179.248.69.1238: .
1093:1093(0) ack 456 win 6432 nop,nop, sack 1 {44:56} (DF)
18:51:43.177329 eth0 64.124.41.177. 209.179.248.69.1238: P
21:557(536) ack 456 win 6432 (DF)
18:51:43.538219 eth0 209.179.248.69.1238 64.124.41.177.: .
456:456(0) ack 557 win 65280 (DF)
18:51:43.538275 eth0 64.124.41.177. 209.179.248.69.1238: P
557:1093(536) ack 456 win 6432 (DF)
18:51:43.538292 eth0 64.124.41.177. 209.179.248.69.1238: P
1093:1629(536) ack 456 win 6432 (DF)
18:51:55.537346 eth0 64.124.41.177. 209.179.248.69.1238: P
557:1093(536) ack 456 win 6432 (DF)
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
"David S. Miller" wrote:
Date:Mon, 06 Nov 2000 18:17:19 -0800
From: Jordan Mendelson [EMAIL PROTECTED]
18:54:57.394894 eth0 64.124.41.177. 209.179.248.69.1238: .
2429:2429(0) ack 506 win 6432 nop,nop, sack 1 {456:506} (DF)
And this is it? The connection dies right here and says no
more? Surely, there was more said on this connection after
this point.
Otherwise I see nothing obviously wrong in these dumps.
I've provided two new dumps of the complete connection lifetime between
2.4.0 and 2.2.16. Both logs show the same client connecting to identical
machines, receiving the same data and then disconnecting.
2.2.16 handles the entire process in under 5 seconds while 2.4.0 takes
over 2 minutes.
Also note that the 2.4.0 connection did not get shut down correctly and
had to send an RST... though this is probably due to the client side
closing down the connection while there was still data on it. Both
machines were under approximately the same load.
It looks to me like there is an artificial delay in 2.4.0 which is
slowing down the traffic to unbearable levels.
Jordan
22:00:39.625351 209.179.245.186.1092 64.124.41.179.: S 4155530:4155530(0) win
8192 mss 536,nop,nop,sackOK (DF)
22:00:39.625437 64.124.41.179. 209.179.245.186.1092: S 1301092473:1301092473(0)
ack 4155531 win 5840 mss 1460,nop,nop,sackOK (DF)
22:00:39.887133 209.179.245.186.1092 64.124.41.179.: . ack 1 win 8576 (DF)
22:00:39.887969 209.179.245.186.1092 64.124.41.179.: . ack 1 win 65280 (DF)
22:00:39.888951 209.179.245.186.1092 64.124.41.179.: P 1:44(43) ack 1 win 65280
(DF)
22:00:39.888964 64.124.41.179. 209.179.245.186.1092: . ack 44 win 5840 (DF)
22:00:39.991515 64.124.41.179. 209.179.245.186.1092: P 1:21(20) ack 44 win 5840
(DF)
22:00:39.991660 64.124.41.179. 209.179.245.186.1092: P 21:557(536) ack 44 win
5840 (DF)
22:00:42.991490 64.124.41.179. 209.179.245.186.1092: P 1:21(20) ack 44 win 5840
(DF)
22:00:43.180946 209.179.245.186.1092 64.124.41.179.: P 44:56(12) ack 21 win
65260 (DF)
22:00:43.180997 64.124.41.179. 209.179.245.186.1092: P 21:557(536) ack 44 win
5840 (DF)
22:00:43.181025 64.124.41.179. 209.179.245.186.1092: P 557:1093(536) ack 56 win
5840 (DF)
22:00:45.685143 209.179.245.186.1092 64.124.41.179.: P 44:456(412) ack 21 win
65260 (DF)
22:00:45.685204 64.124.41.179. 209.179.245.186.1092: . ack 456 win 6432
nop,nop, sack 1 {44:56} (DF)
22:00:49.171046 64.124.41.179. 209.179.245.186.1092: P 21:557(536) ack 456 win
6432 (DF)
22:00:49.470193 209.179.245.186.1092 64.124.41.179.: . ack 557 win 65280 (DF)
22:00:49.470233 64.124.41.179. 209.179.245.186.1092: P 557:1093(536) ack 456 win
6432 (DF)
22:00:49.470248 64.124.41.179. 209.179.245.186.1092: P 1093:1629(536) ack 456
win 6432 (DF)
22:01:01.461056 64.124.41.179. 209.179.245.186.1092: P 557:1093(536) ack 456 win
6432 (DF)
22:01:01.755362 209.179.245.186.1092 64.124.41.179.: . ack 1093 win 65280 (DF)
22:01:01.755428 64.124.41.179. 209.179.245.186.1092: P 1093:1629(536) ack 456
win 6432 (DF)
22:01:01.755451 64.124.41.179. 209.179.245.186.1092: P 1629:1825(196) ack 456
win 6432 (DF)
22:01:25.751048 64.124.41.179. 209.179.245.186.1092: P 1093:1629(536) ack 456
win 6432 (DF)
22:01:26.171932 209.179.245.186.1092 64.124.41.179.: . ack 1629 win 65280 (DF)
22:01:26.171979 64.124.41.179. 209.179.245.186.1092: P 1629:1825(196) ack 456
win 6432 (DF)
22:02:14.171052 64.124.41.179. 209.179.245.186.1092: P 1629:1825(196) ack 456
win 6432 (DF)
22:02:14.499920 209.179.245.186.1092 64.124.41.179.: . ack 1825 win 65084 (DF)
22:02:14.499944 64.124.41.179. 209.179.245.186.1092: P 1825:1847(22) ack 456 win
6432 (DF)
22:02:16.168708 209.179.245.186.1092 64.124.41.179.: F 456:456(0) ack 1825 win
65084 (DF)
22:02:16.181061 64.124.41.179. 209.179.245.186.1092: . ack 457 win 6432 (DF)
22:02:16.281724 64.124.41.179. 209.179.245.186.1092: F 1847:1847(0) ack 457 win
6432 (DF)
22:02:16.477943 209.179.245.186.1092 64.124.41.179.: . ack 1825 win 65084
nop,nop, sack 1 {1847:1848} (DF)
22:03:50.491063 64.124.41.179. 209.179.245.186.1092: P 1825:1847(22) ack 457 win
6432 (DF)
22:03:50.680141 209.179.245.186.1092 64.124.41.179.: R 4155987:4155987(0) win 0
(DF)
22:00:01.684927 209.179.245.186.1091 64.124.41.136.: S 4033171:4033171(0) win
8192 mss 536,nop,nop,sackOK (DF)
22:00:01.685021 64.124.41.136. 209.179.245.186.1091: S 1261602556:1261602556(0)
ack 4033172 win 32696 mss 536,nop,nop,sackOK (DF)
22:00:01.916120 209.179.245.186.1091 64.124.41.136.: . ack 1 win 8576 (DF)
22:00:01.916191 209.179.245.186.1091 64.124.41.136.: . ack 1 win 65280 (DF)
22:00:01.916981 209.179.245.186.1091 64.124.41.136.: P 1:44(43) ack 1 win 65280
(DF)
22:00:01.917032 64.124.41.136. 209.179.245.186.1091: . ack 44 win 32696 (DF)
22:00:02.121143 64.124.41.136.
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
"David S. Miller" wrote: Date: Mon, 06 Nov 2000 21:20:39 -0800 From: Jordan Mendelson [EMAIL PROTECTED] It looks to me like there is an artificial delay in 2.4.0 which is slowing down the traffic to unbearable levels. No, I think I see whats wrong, it's nothing more than packet drop. Looking at the equivalent 220 traces, the only difference appears to be that the packets are not getting dropped. I would like to note that these two machines the windows client is connecting to are sitting on the exact same switch connected to the same provider handling identical user loads. Alexey, do you have any other similar reports wrt. the new MSS advertisement scheme in 2.4.x? Jordan, you mentioned something about possibly being "bandwidth limited"? Please, elaborate... 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. Jordan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Date: Mon, 06 Nov 2000 22:13:23 -0800 From: Jordan Mendelson [EMAIL PROTECTED] 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. Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
"David S. Miller" wrote:
Date: Mon, 06 Nov 2000 22:13:23 -0800
From: Jordan Mendelson [EMAIL PROTECTED]
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
23:36:15.252817 209.179.194.175.1084 64.124.41.179.: S 370996:370996(0) win 8192
mss 536,nop,nop,sackOK (DF)
23:36:15.252891 64.124.41.179. 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.: . ack 1 win 8576 (DF)
23:36:16.160461 209.179.194.175.1084 64.124.41.179.: . ack 1 win 65280 (DF)
23:36:16.160488 209.179.194.175.1084 64.124.41.179.: P 1:44(43) ack 1 win 65280
(DF)
23:36:16.160506 64.124.41.179. 209.179.194.175.1084: . ack 44 win 5840 (DF)
23:36:16.261533 64.124.41.179. 209.179.194.175.1084: P 1:21(20) ack 44 win 5840
(DF)
23:36:16.261669 64.124.41.179. 209.179.194.175.1084: P 21:557(536) ack 44 win
5840 (DF)
23:36:19.261055 64.124.41.179. 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.: P 44:56(12) ack 21 win
65260 (DF)
23:36:19.450788 64.124.41.179. 209.179.194.175.1084: P 21:557(536) ack 44 win
5840 (DF)
23:36:19.450820 64.124.41.179. 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.: P 44:456(412) ack 21 win
65260 (DF)
23:36:22.281308 64.124.41.179. 209.179.194.175.1084: . ack 456 win 6432
nop,nop, sack 1 {44:56} (DF)
23:36:25.441061 64.124.41.179. 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.: . ack 557 win 65280 (DF)
23:36:25.701841 64.124.41.179. 209.179.194.175.1084: P 557:1093(536) ack 456 win
6432 (DF)
23:36:25.701859 64.124.41.179. 209.179.194.175.1084: P 1093:1629(536) ack 456
win 6432 (DF)
23:36:37.701091 64.124.41.179. 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.: . ack 1093 win 65280 (DF)
23:36:38.026826 64.124.41.179. 209.179.194.175.1084: P 1093:1629(536) ack 456
win 6432 (DF)
23:36:38.026839 64.124.41.179. 209.179.194.175.1084: P 1629:1847(218) ack 456
win 6432 (DF)
23:37:02.021068 64.124.41.179. 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.: . ack 1629 win 65280 (DF)
23:37:02.328189 64.124.41.179. 209.179.194.175.1084: P 1629:1847(218) ack 456
win 6432 (DF)
23:37:50.321057 64.124.41.179. 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.: . ack 1847 win 65062 (DF)
23:37:50.673068 64.124.41.179. 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.: F 456:456(0) ack 1847 win
65062 (DF)
23:38:00.181055 64.124.41.179. 209.179.194.175.1084: . ack 457 win 6432 (DF)
23:38:00.187291 64.124.41.179. 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.: . ack 1847 win 65062
nop,nop, sack 1 {1868:1869} (DF)
23:39:26.671050 64.124.41.179. 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.: R 371453:371453(0) win 0
(DF)
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.: S 370996:370996(0) win 8192
mss 536,nop,nop,sackOK (DF)
22:34:35.669892 64.124.41.179. 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.: . ack 1 win 8576 (DF)
22:34:35.670653 209.179.194.175.1084 64.124.41.179.: . ack 1 win 65280 (DF)
22:34:35.674484 209.179.194.175.1084 64.124.41.179.: P 1:44(43) ack 1 win 65280
(DF)
22:34:36.049808 64.124.41.179. 209.179.194.175.1084: . ack 44 win 5840 (DF)
22:34:36.069773 64.124.41.179. 209.179.194.175.1084: P 1:19(18) ack 44 win 5840
(DF)
22:34:36.069837 64.124.41.179. 209.179.194.175.1084: P 19:553(534) ack 44 win
5840 (DF)
22:34:39.049788 64.124.41.179. 209.179.194.175.1084: P 1:21(20) ack 44 win 5840
(DF)
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Date: Mon, 06 Nov 2000 22:44:00 -0800 From: Jordan Mendelson [EMAIL PROTECTED] 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. 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF) 22:34:36.069837 64.124.41.179. 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. 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.: 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. 209.179.194.175.1084: P 21:555(534) ack 44 win 5840 (DF) 22:34:39.245208 64.124.41.179. 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.: 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. 209.179.194.175.1084: P 1:21(20) ack 44 win 5840 (DF) 23:36:16.261669 64.124.41.179. 209.179.194.175.1084: P 21:557(536) ack 44 win 5840 (DF) 23:36:19.261055 64.124.41.179. 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. 209.179.194.175.1084: P 1:19(18) ack 44 win 5840 (DF) 22:34:36.069837 64.124.41.179. 209.179.194.175.1084: P 19:553(534) ack 44 win 5840 (DF) 22:34:39.049788 64.124.41.179. 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Date: Tue, 7 Nov 2000 08:03:42 +0100 From: Andi Kleen [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
"David S. Miller" wrote: Date: Mon, 06 Nov 2000 22:44:00 -0800 From: Jordan Mendelson [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Date: Mon, 06 Nov 2000 23:16:21 -0800 From: Jordan Mendelson [EMAIL PROTECTED] "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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Date: Tue, 7 Nov 2000 08:16:04 +0100 From: Andi Kleen [EMAIL PROTECTED] 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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
"David S. Miller" wrote: Date: Mon, 06 Nov 2000 23:16:21 -0800 From: Jordan Mendelson [EMAIL PROTECTED] "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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor TCP Performance 2.4.0-10 - Win98 SE PPP
Date: Mon, 06 Nov 2000 21:20:39 -0800
From: Jordan Mendelson [EMAIL PROTECTED]
It looks to me like there is an artificial delay in 2.4.0 which is
slowing down the traffic to unbearable levels.
No, I think I see whats wrong, it's nothing more than packet drop.
The large gaps in time seem to be due to packets being dropped:
22:00:39.991515 64.124.41.179. 209.179.245.186.1092: P 1:21(20) ack 44 win 5840
(DF)
22:00:39.991660 64.124.41.179. 209.179.245.186.1092: P 21:557(536) ack 44 win
5840 (DF)
3 seconds pass, retransmit time out.
22:00:42.991490 64.124.41.179. 209.179.245.186.1092: P 1:21(20) ack 44 win 5840
(DF)
Linux retransmits dropped data.
22:00:43.180946 209.179.245.186.1092 64.124.41.179.: P 44:56(12) ack 21 win
65260 (DF)
Windows95 responds, acknowledges up to byte 21.
22:00:43.180997 64.124.41.179. 209.179.245.186.1092: P 21:557(536) ack 44 win
5840 (DF)
22:00:43.181025 64.124.41.179. 209.179.245.186.1092: P 557:1093(536) ack 56 win
5840 (DF)
22:00:45.685143 209.179.245.186.1092 64.124.41.179.: P 44:456(412) ack 21 win
65260 (DF)
Linux resends bytes 21:556 and sends new data from 557:1093.
Windows95 sends new data and ACKs only up to 21 (meaning presumably
that all bytes sent by Linux this time were dropped).
22:00:45.685204 64.124.41.179. 209.179.245.186.1092: . ack 456 win 6432
nop,nop, sack 1 {44:56} (DF)
Linux acknowledges data received from Windows95 machine.
A retransmit timeout occurs on the lost data.
22:00:49.171046 64.124.41.179. 209.179.245.186.1092: P 21:557(536) ack 456 win
6432 (DF)
22:00:49.470193 209.179.245.186.1092 64.124.41.179.: . ack 557 win 65280 (DF)
Linux resends 21:557, Windows95 (finally) acknowledges it.
Looking at the equivalent 220 traces, the only difference appears to
be that the packets are not getting dropped.
Alexey, do you have any other similar reports wrt. the new MSS
advertisement scheme in 2.4.x?
Jordan, you mentioned something about possibly being "bandwidth
limited"? Please, elaborate...
Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
