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