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
> - it removed all the packets from device queues, when user
> was tired to wait for result.
This one is very good
> But it did not make any device based flow control yet.
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
> I invented one solution: to create sk->congestion_notify
> callback, and to set it for tcp to normal VJ { ss=cwnd/2; cwnd=1; }
> and for dgrams to nothing. So that, when device is conjested,
> it calls this callback, but does not drop packet, until a second
> threshold (2*tx_queue_len?) is exceeded or until sk->ssthesh != 1.
> Yesterday it looked very clever :-)
Remember this is not just a TCP issue. UDP gains more than most from such
feedback effects.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu