[plug] Scheduling Problems

Brad Campbell brad at seme.com.au
Thu May 18 12:36:06 WST 2000


Brad Campbell wrote:
> 
> I know that this is a LINUX users group, and as such, questions
> about LINUX are usually shunned or skirted around.. ;p) BUT..
> 
> I have written a program that Polls an RS485 Network from
> a couple of serial ports.
> I understood that when a process blocks on a syscall, the scheduler
> selects the next available runnable process.

Thanks to all who replied, here is a clarification and some more detail.

To poll a device, I send 4 Bytes to it with an fdWrite()
The device sees these and responds within 1/2 a bit time with 2 bytes
Immediately after the fdWrite() I perform a Select() on the handle
with a timeout of 50mSec.
I can't do a blocking read, in case I have a device go down. I need 
to be able to perform a timeout and remove that device from the polling
loop.
The Transmit enable on the RS485 line is controlled by external hardware
so there are NO timing issues. If it took 10 seconds to transmit the 1st
4 bytes, the device will still respond with 2 bytes.

Observing the comms on a digital storage cro, with a standard kernel
I get a 2ms Blast of data (Thats 1 4 byte poll and 1 2 byte response)
I then get 8ms of idle time, and the process repeats. (thus 10ms) which
someone mentioned was the kernel timeslice.

It sounds like it's resceduling on the select() call, and waiting until
the process gets re-selected 10ms later. Confused? I am.
What I'm going to do is insert some IOCTL's in the software, toggling the rts
line, so I can watch on the cro and see where the blocking occurs.

Is it possible that a select() call with a timeout specified, actually 
blocks the process in the running state until either the timeout expires
or it recieves data ?
Even then I can't understand why that would be a problem, because the only
wait time involved is between the kernel sending the 4 bytes to the port, and
the 2 bytes becoming available in the file descriptor.

Oh, I forgot to mention, I'm writing this in FPC Pascal too, not C.
Not that that matters, as Pascal makes the system calls directly and has no
interaction with any system librarys.

But as I said before, making HZ = 300 speeds up the polling by a factor of 3

I'll try the IOCTLS and let you know if I can see where it blocks..

-- 
Brad....
"The ultimate result is that some innovations that would
truly benefit consumers never occur for the sole reason
that they do not conincide with Microsoft's self-interest"
- Judge Thomas Penfield Jackson
         /"\
         \ /     ASCII RIBBON CAMPAIGN
          X      AGAINST HTML MAIL
         / \



More information about the plug mailing list