[ros-kernel] Process scheduler / timer resolution

[Mike Nordell]

Andrew Greenwood wrote:

> I was browsing the ReactOS bug tracker recently, and came across a listed
> bug about the kernel timer updating 100 times a second, as opposed to 1000
> times.

If so, that'd be the error of hal\halx86\timer.c. Look for the macros
MILLISEC and HZ. It's AFAIK finally the macro LATCH, used to program
TMR_CNT0, affecting the interrupt rate.

However, I'm not convinced NT triggers 1k interrups/s. I just ran perfmon on
NT5, and on this otherwise idle system I had just 175 interrupts/second.

> I recall that it's possible to set the system timer to fire an interrupt
at
> a particular rate. And surely by increasing that rate, the kernel
scheduler
> will switch threads more often, and thus the result will be lower latency
> and possibly smoother multithreading.

Since you mentioned latency, lets for the sake of argument assume you have
at least two threads with the same priority (let's assume priority inversion
isn't even in the equation - which AFAIK it actually isn't in ROS yet)
competing for CPU time.

Currently ROS doesn't even use a thread quantum, why it switches thread on
every timer interrupt. 100 times/second isn't enough? You have an actual
need to switch at a faster rate (and are prepared to let everyone using ROS
pay the penalty of spending an order of magnitude more time just in the
scheduler/thread-switcher)?

Considering thread-switches are quite expensive (feel free to call this the
understatement of the week), this is not something I would want to see
unless backed up with some pretty good arguments explaining in detail why
it'd be required.


/Mike