> Here is a third-hand suggestion that popped up in a reply to a similar
> problem on comp.os.linux.networking:
>
> # RFC 1323 "TCP Extensions for High Performance"
> echo -n 0 > /proc/sys/net/ipv4/tcp_window_scaling
> echo -n 0 > /proc/sys/net/ipv4/tcp_timestamps
> # RFC 2018
> echo -n 0 > /proc/sys/net/ipv4/tcp_sack
> It turns off some "bandwidth*delay product" optimizations. We'd be
> interested in whether it works for you or not.
Alas, no. I'm fairly convinced that's a PPP thing, if it was happening to
all net drivers someone would have noticed before, surely? Actually, the fact
that few people have noticed it with PPP worries me, maybe I'm barking up
utterly the wrong tree?
The pattern I've noticed so far seems to be that whenever the sending host
queues multiple segments in quick succession, the remote host only ever sees
the first:
We see:
00:33:46.748313 loth.1131 > moria-eth.1883: P 1:1449(1448) ack 1 win 32120 <nop,nop,timestamp 1020677 71896360> (DF)
00:33:46.749684 loth.1131 > moria-eth.1883: P 1449:2897(1448) ack 1 win 32120 <nop,nop,timestamp 1020677 71896360> (DF)
00:33:47.366914 moria-eth.1883 > loth.1131: . ack 1449 win 31856 <nop,nop,timestamp 71896444 1020677> (DF) [tos 0x10]
The remote sees:
00:33:58.678060 loth.1131 > moria-eth.1883: P 1:1449(1448) ack 1 win 32120 <nop,nop,timestamp 1020677 71896360> (DF)
00:33:58.678334 moria-eth.1883 > loth.1131: . ack 1449 win 31856 <nop,nop,timestamp 71896444 1020677> (DF) [tos 0x10]
and again, later, we see:
00:33:47.367056 loth.1131 > moria-eth.1883: P 2897:4345(1448) ack 1 win 32120 <nop,nop,timestamp 1020739 71896444> (DF)
00:33:47.367574 loth.1131 > moria-eth.1883: P 4345:5793(1448) ack 1 win 32120 <nop,nop,timestamp 1020739 71896444> (DF)
00:33:47.936948 moria-eth.1883 > loth.1131: . ack 1449 win 31856 <nop,nop,timestamp 71896502 1020677> (DF) [tos 0x10]
but the remote only sees:
00:33:59.249165 loth.1131 > moria-eth.1883: P 2897:4345(1448) ack 1 win 32120 <nop,nop,timestamp 1020739 71896444> (DF)
00:33:59.249450 moria-eth.1883 > loth.1131: . ack 1449 win 31856 <nop,nop,timestamp 71896502 1020677> (DF) [tos 0x10]
This strikes me as something that should be a Big Clue, but I don't know
enough about TCP or the networking code to be able to use it. I'm going to
go read some RFCs and dig my way into the network code. Joy ;-)
-- Ah, but you're forgetting Rimmer directive 273 which states just as clearly, "No chance you metal bastard!"- 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/