[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ppp
Subject:    RE: Using PPPD pty option and script: controlling stdin buffer size?
From:       Arne Lie <Arne.Lie () sintef ! no>
Date:       2010-10-13 12:19:52
Message-ID: 291B2C7721AC7B49AD11449A2883992E2E0DF5661E () SINTEFEXMBX01 ! sintef ! no
[Download RAW message or body]

> -----Original Message-----
> From: James Carlson [mailto:carlsonj@workingcode.com]
> Sent: 13. oktober 2010 14:09
> To: Arne Lie
> Cc: wharms@bfs.de; 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
���{.n�+�������+%�����ݶ��w��{.n�+����{���i�)���w*jg��������ݢj����G���������j:+v���w�j�m��������w�����f���h������٥



[prev in list] [next in list] [prev in thread] [next in thread]