> This BTW is wrong behaviour for the general case. Phil Karn explained
> it rather forcefully on tcp group - its broken for the case you have
> high packet loss upstream of you. Your optimisation does bad things then
Yes :( Actually, the thing that I speak about is valuable only
when your host is attached via slow link, and this link is the only
bottleneck. This situation is common.
> You can see that in 2.0.x if you have a big ftp going and try and
> do other stuff. It stamps most unfairly on things. Cutting the tx_queue_len
> down to 4 hides the worst fortunately
Did I correctly understand it? So: let queue be very short,
so that slowness of link will not result in overestimate of rtt.
When a packet goes to blackhole, congestion avoidance will feel it,
but rtt will be estimated more-or-the-less correctly. Is it true?
Or I say something silly?
> Remember this is not just a TCP issue. UDP gains more than most from such
> feedback effects.
Well, udp is happy with sndbuf. Setting sndbuf to a reasonable
value (which includes sizeof(sk_buff) :-)), so that packets never
dropped locally, we can achieve link speed with 64 byte packets
on 100Mbit link.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu