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?
>
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
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.
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.
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
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
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.
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
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
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,
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
"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
>
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
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
"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
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
>
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
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
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,
"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
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
"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
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
"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
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
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
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/
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
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?
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
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
"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
"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
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
"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
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
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
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
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
"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
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
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
"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
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
44 matches
Mail list logo
