[plug] Scheduling Problems

[Mike Holland]

On Wed, 17 May 2000, Brad Campbell wrote:

> I understood that when a process blocks on a syscall, the scheduler
> selects the next available runnable process.

If there is one. In your case it should halt until the serial port
generates an interupt for incoming data, yes?
 
  Are you actually getting interrupts at all? It sounds like you may
effectively be polling the serial ports.

Maybe show the code. Do you test why select returned, e.g. EINTR, or just
check for data?

> I would have thought that if this was the only runnable process
> on the system, after I recieved data, and looped back to the
> start to do it again, I would be going about as fast as is
> possible in a tight loop.

No, select() should block until timeout, or data is available, or
interupted. Or do you give a zero timeout?

Maybe even a zero timeout causes a wait until the next clock tick - that
would be logical. The timeout value is only a minimum.

But why isnt an interrupt causing select to return sooner? 

> The only thing I can think of, is I'm waiting on the bottom 
> half interrupt handlers to run to distibute the recieved data,
> and this gets sped up with a finer HZ grain.

I dont think it works that way. But IANAKH.

> FYI I'm transmitting 4 Bytes and recieving 2 Bytes at 38400
> Which equates to 2ms total comms time.

Does the far end reply instantly?

Let us know how it goes, 

Mike Holland  <mike at golden.wattle.id.au>
                          --==--
antispam: rot 13 my email xor with the first 20 letters of the king james
bible and run crypt to mail me.