[plug] Scheduling Problems

[Tom Atkinson]

Brad Campbell wrote:
> 
> I have written a program that Polls an RS485 Network from
> a couple of serial ports.
> 
> so I'm transmitting some data to a file handle (ttyS3) and then
> using a select() on that handle to notify me when I have data
> available.

Why are you using select()?  Does a blocking read not do exactly what
you want? (i.e return when there is 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.

Yes, that is exactly my understanding of how things work.  I have
written a device driver for Linux, so I learnt a bit about blocking,
sleep and waking up.

> 
> Lets say I'm polling 7 Units, on a standard kernel, I can poll
> these 13 times a second, which is 91 loops a second.
> 
> Not very fast at all.

How are you measuring this?  Do you open the device for reading with
O_NONBLOCK then count how many times per second you are able to make a
read call?  Or does a "poll" involve writing some data to the port as
well?  Please elaborate.


> If I modify include/asm/param.h and take HZ from 100 to 300
> I poll this lot 40 times a second.
> or 280 loops per second.
> 
> Now, I understand by doing this, what I'm doing is breaking
> the scheduler's time period into smaller pieces, thus each
> task has a smaller run time per cycle.


The HZ define is there so that device drivers know what speed the system
clock is ticking at (so that they can make very small waits; which are
specified not as a time period, but as some number of clock ticks, known
as "jiffies" in Linux).  If you change the code that programs the clock,
so that it is ticking at a different rate, then you must change the HZ
define - but only then.

Perhaps the HZ define is also used by the code which programs the clock
tick rate - in which case your clock is indeed ticking 3 times faster
than normal.  The obvious tradeoff with the faster tick is that the
scheduler now runs 300 times per second, instead of just 100, meaning
that more CPU time is spent in the scheduler.

If the HZ define does NOT determine what the clock rate is set to, then
you have a problem on your hands because your device drivers now think
that the clock is ticking 3 times faster than it really is - thus
hardware delays will be too short, which should lead to errors.


> What I don't understand is why this should speed things up
> as I block the process anyway at the point where it waits
> for a response. Thus I should be forcing a reschedule long
> before the scheduler interrupts the process.

Agreed.


> 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.

Quite possibly.  Perhaps sped up erroneously!

Inside the device driver, when it chooses to "wait" for a short time, it
asks the kernel to sleep for a certain duration.  This duration is
specified as some number of clock ticks (which should be calculated
using the HZ define).

These little sleeps are a necessary evil when doing device I/O.  They
allow for TTL state change/ settle time, recharge, etc, etc.

Did this device driver get recompiled after you changed the HZ define? 
Does it calculate the sleep duration properly? or does it just assume
100HZ because it is x86 architecture?

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

Please let me know what you find out - I will be embarking on a project
soon where sleep durations during reads from serial ports may be quite
important.

Best regards,
Tom Atkinson