Messages in this thread | | | Date | Wed, 23 Jul 1997 14:33:30 +0100 (WET DST) | From | "Manuel J. Galan" <> | Subject | Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions |
| |
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
| |