[ros-kernel] Process scheduler / timer resolution

Mike Nordell tamlin at algonet.se
Tue Mar 9 14:18:19 CET 2004

Andrew Greenwood wrote:

[snipped large over-quote]

> I just recall reading somewhere that a faster timer interrupt rate
> multitasking performance.

That is never the case. Ever. Performance is always reduced with increased
interrupt rates. Always.

> Perhaps this is not the issue here, and, like you
> said, ReactOS doesn't use a thread quantum, so presumably having thread
> quantums would improve things?

Implementing thread quantum would mean (perhaps even much) less time would
be spent serving each timer interrupt - leaving more time for the threads to
actually do the work they're supposed to do. IMNSHO that would indeed be an

But I'm still not sure what you intended with "improve things", especially
the "things". Would you care to elaborate?

> The only practical reason for finer interrupt-tuning would be for
> lower-latency with realtime things like audio programs.

1. Realtime has a very specific meaning. NT (and therefore ROS) can not be
realtime as-is.
2. If you have a specific application where you need >100
thread-switches/second, just to handle your audio application, I think you
- need a real-time OS such as QNX, vxWorks, or even DOS(!)
- need a device-driver in ROS

> Or am I missing something?

I don't know, and to not begin speculating whether that's the case or not
perhaps you could explain a scenario you think a higher thread-switching
rate/lower latency would be required. Please take into account that if you
really need to be the "top dog" on every schedule, you're free to run the
process at "Realtime" priority.


More information about the Ros-kernel mailing list