It's the same either on or off. This is something that snuck in
fairly recently. One day I was trying to get to ftp.x.org, and
this happened. I figured they :) were having troubles and ignored
it. When 'their' problem didn't go away in a couple of days, I got
suspicious. When the same exact failure happened with porcupine, I
remembered hearing about /proc/sys/net/ipv4/tcp_timestamps and gave
it a shot. This snuck in after a kernel upgrade, not an isdn
upgrade fwiw.
It's a bug in the other end.
How do I know this? :-) Because now that you mention ftp.x.org I have
seen this problem too and watched the traces carefully. What I saw is
that with timestamps enabled, if there is a dropped packet and either
a fast or normal retransmit happena, ftp.x.org backs off for a _long_
time and takes forever to retransmit.
I think ftp.x.org need to apply any updates necessary to their (what
appears to be a) BSD derived system. It's definately a bug in the
sender (ftp.x.org) and not in Linux-2.2.x
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.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/