Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions
Manuel J. Galan (manolow@step.es)
Wed, 23 Jul 1997 14:33:30 +0100 (WET DST)
On 22-Jul-97 Rob Riggs wrote:
>
>On 22-Jul-97 Bill Hawes wrote:
>>Rob Riggs wrote:
>>> There was a false assumption made in the serial code. It assumed
>>> that an entire run through the timer task queue was made every
>>> clock tick. That may or may not happen, depending on how many
>>> other tasks need to be run, whether we have to sleep, and the
>>> number of interrupts occuring.
>>
>>If the timer queue is run at all, the entire queue is run -- there's no
>>provision for only calling some of the tasks. So analyzing your
>>problem reduces to finding reasons why the timer queue might miss a
>>turn.
>
>Yes, I am aware that the entire queue is run. My point was that
>it can take longer than one jiffy to complete all of the tasks
>on the timer task queue. In that case it "misses" running the
>task queue for the next clock tick because it is *still* running
>the queue for the previous tick. In that case, an entire run
>through the timer task queue is not made every clock tick.
>
>>If we rule out disabling because of page faults, my next hypothesis
>>would be that PPP processing itself may be taking sufficiently long that
>>the timer starts missing ticks. This might make sense considering that
>>existing flow control mechanisms are triggered by the n_tty receive
>>buffer filling, not by processing time causing missed clock ticks.
>
>Yes, but why not just do flow control directly in the serial driver?
>I have been running my serial.c modified to do flow control inside
>the receive_chars() interrupt routine and am getting 13.5K/s FTP
>rates running non-compressed 128K ISDN. It'll be even faster once
>I dump the diagnostic code and tune it.
>
>>I'll take a look at the PPP code; it may be that we need a way to invoke
>>flow control based on time rather than buffer space considerations.
>
>I don't think it is necessary.
>
>-Rob