[plug] Scheduling Problems

[Brad Campbell]

Mike Holland wrote:
> 
> On Thu, 18 May 2000, Leon Brooks wrote:
> 
> > Brad Campbell wrote:
> > > I can't do a blocking read, in case I have a device go down.
> >
> > Yes you can! You're not on a single-user machine. Have a watchdog
> > thread/process tap the main thread/process on the shoulder if it dies.
> 
> Could you also try setitimer() to interrupt a blocking read?
> 
> Brad - maybe just to be sure, use strace to check pascal isnt doing any
> unexpected syscalls.

Alright, tracked the delay down to the fdRead call using blocking IO
or the Select call using Non-blocking io.
Seems maybe the kernel isn't making the data available until the end
of the 10ms Timeslice.
I'll do some digging in the kernel sources and have a look at the
bottom half interrupt handlers.

What is happening, is the task transmits the data, then blocks on the
recieve command and the kernel puts it to sleep, not waking it up for
10ms. I can see this behaviour clear as day on the Cro.

I did a dodgy select loop, where I polled select with a timeout of 0
repeatedly until it returned a value, and toggled the rts line from inside the loop.

The rts line toggled for the whole of the 10ms slice.. which means the kernel
is not notifying the task of data available until the end of that timeslice/
start of the next timeslice.

so it looks like I'm stuffed, unless I up the HZ value, which does reduce the
timeslice size accordingly. As measured with the cro..

I might condense this problem down a bit and post it to linux-kernel..
Good Idea ?


-- 
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
         / \