Arne Lie wrote: > [Arne::] With all the respect, congestion control needs normally packet loss > due to traffic overload to respond correctly, yes? No. You've also got measurable delay, which I think is the key to solving this problem. > With the large buffering > of stdin this do not happen before long... We're dealing with underwater > networks with severely slow links and > large propagation delays. We need relative short buffers to avoid seeing too > big RTTs. Default PPP interfaces are set up with txqueuelen = 3, which is fine. > However, when the *effective* queue size is this plus the stdin buffering, which > we do not know the size of in bytes, but is in order of minutes (!) in RTT for such > slow links, then it starts to get an annoyance. What would you do if the "excessive" buffering were in some box in the middle of the network? For many older systems, transmit queues of 50 packets or more are not at all uncommon. I expect that an algorithm that tracks both round-trip latency and throughput (using feedback from the peer) should be able to detect when increasing the send rate only causes latency to go up and doesn't change throughput. That's the optimal rate. If you feel like hacking your kernel anyway then good luck with that, but I suspect you'll be back to this problem in the future. -- James Carlson 42.703N 71.076W <carlsonj@xxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-ppp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
