Thanks for the report - this pinpoints the change pretty well, as there
is just one (small) change between 5 and 6 in tcp_output.c..
> ping waterf -> hur 140-160msec
> ping waterf -> miriam 1.0-1.6msec
> ping hur -> miriam 0.6-1.1msec
>
> Setup:
>
> Linux 2.0.6 (waterf)
> |
> PPP Link
> |
> Linux 2.0.6 (hur)
> |
> Ethernet
> |
> Linux 2.0.6 (miriam)
>
> Sometimes I have doubts that Alan knows what he is doing.
Don't blame alan, blame me. It's the small patch I made to
"tcp_send_delayed_ack()" in the mistaken belief that it couldn't possible
break anything at all, and that it cleaned up and simplified some code (I
was right on the second count, but seemingly not on the first one).
HOWEVER, now that I look a bit more closely at your report, it starts making
less and less sense. Notably, "ping" doesn't use TCP at all, so the only
change that is in the 5->6 upgrade simply _cannot_ affect ping latency. And
the _longer_ trip to miriam from waterf (that still uses PPP) doesn't seem
affected.
The only thing the 2.0.5->6 upgrade does is that it makes a lot more TCP
ack's happen from timers rather than from the TCP reception code. As
such, it changes some timings wrt the network packets, AND this might
break if the PPP driver has a race condition that shows up for that case.
Anyway, try just reverting on the tcp_output.c patch in 2.0.6 (it's a rather
small one), and if that fixes the problem then I guess we'll just have to go
back. However, this behaviour makes me suspect more and more that there is
something broken in the PPP (or serial code) timings, and that the TCP change
just happens to make that show up more (so the TCP change itself isn't the
bug, it just triggers the _real_ bug - not something we want to necessarily
look into in the 2.0.x series, though).
Linus