Messages in this thread | | | Date | Tue, 22 Jul 1997 18:06:45 -0400 | From | Bill Hawes <> | Subject | Re: 2.0.30 serial.c, ppp.c and pppd-2.2 questions |
| |
Theodore Y. Ts'o wrote: > I can't help thinking that we're missing something big though; if the > flip buffer processing is getting delayed this long, there's something > wrong going on.
I agree completely. We need to find why the buffers aren't being flipped fast enough; if the flip buffers are overflowing, other tasks on the timer queue will be having problems as well.
In the case of PPP, the problem seems to be that most or all of the processing is being done in the code called from the timer queue. Granted that this saves a copy to an intermediate buffer, but it means that lots of work identifying frames and even decompression are being done in what was intended as a quick time slice. (PPP is even allocating memory from the tqueue.) If the PPP code takes too long, then the whole timer queue may miss a tick.
This is really a design issue, but it seems to me that the PPP code would be better off using the tqueue code to copy to a buffer, maybe marking frames, but deferring other processing to a higher level.
It would be nice if we could come up with a short-term workaround for Rob's problem, but the only thing I can think of is to somehow detect that the flip buffer is filling (say, more than half full), and trigger some flow-control option.
Regards, Bill
| |