> -----Original Message----- > From: James Carlson [mailto:carlsonj@xxxxxxxxxxxxxxx] > Sent: 13. oktober 2010 14:09 > To: Arne Lie > Cc: wharms@xxxxxx; ppp Linux > Subject: Re: Using PPPD pty option and script: controlling stdin buffer > size? > > 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. [Arne::] Thanks for your input, James. Kernel hacking is out of the question, I guess... ;-) We do however already have an alternative, where we use a specially developed kernel module sw as "tty device driver", and where we have better control over the buffering. It has not proven perfectly stable though for all possible Linux platforms, but might be a better option for further refinements/debugging, than the pure user mode solution that we have discussed here. thanks a lot, Arne ÿô.nlj·Ÿ®‰†+%ŠË±é¥Šwÿº{.nlj·¥Š{±þšiþ)íè jg¬±¨ ¶‰šŽŠÝjÿ¾«þG«é¸ ¢·¦j:+v‰¨Šwèm¶Ÿÿþø®w¥þŠà£¢·hšâÿ†Ù
