Last edit: 05-03-17 Graham Wideman

Data Acquisition

Contents

• This Page
  • The Basics
  • Process and Thread Priorities
  • Scheduler Granularity
  • Other Notes
  • References
• Other Pages
  • SkedGran  Test utility to measure scheduler granularity on your system.

The Basics

In order to understand timing issues under Windows it's necessary to understand how multitasking works for these operating systems.

The operating system views each application and service as a process, which may incorporate 1 or more threads of execution.  A key part of the OS is the mechanism which runs applications and services, and provides the approximate effect of running them all at once (multitasking) by allocating time slices to each in turn according to priority levels.  The W95/98/NT/2000 operating systems are refered to as preemptive mulitasking because at regular intervals the OS "preempts" whichever thread is running in order to reevaluate which is the most deserving thread.

So, of great pertinence to the subject of timing are the following issues:

• How process and thread priorities work?
• What is the time granularity of polling routines?
• How long how long does a newly awoken thread or newly ready scheduled callback have to wait before it runs?

Process and Thread Priorities

Overall thread priority is determined by three factors:

• Priority of the process
• Priority of the thread
• Priority "boost"

An exhaustive table of priority combinations is given in the MSDN reference above.   I've summarized the resulting overall priorities in the following table.

Notes

Bg and Fg indicate Background and Foreground. "Bg?" means that the MSDN chart doesn't specifically indicate background, but elsewhere provides a value for Foreground.

Boost

The table above doesn't include the details of the Boost mechanism, see the MSDN reference for details.  In brief, the scheduler may boost the priority of certain threads under certain circumstances, including the thread being part of a process that came to the foreground, or it's a thread that just became ready. The boost strategy varies by OS, and may be impacted by user settings.

Priority Inversion

Each OS includes a strategy to avoid getting stuck when a a high-priority thread is waiting for a low-priority thread that can't get a time-slice. See MSDN for details.

Other interesting features:

• Callbacks and Wake-ups get Priority of Thread that Created Them:    Scheduled callbacks (timeSetEvent etc), and the awakening of threads put to Sleep get the priority of the thread that created them.  If the thread's priority is changed after the thread has scheduled a callback, then I think the callback inherits the new priority.
  
• Threads of RealTime Processes Always Have Higher Priority!  Note from this table that all threads in a process with RealTime priority are higher priority than other non-RealTime classes, regardless of thread priority.  

  This would be of most concern if when writing an app which is supposed to service hardware on a timely basis (ie: you don't have a low-level driver for the hardware), and you are trying to use callbacks or thread wake-ups to do this. In either case, the callback or thread wake-up will only occur at the requested time if higher-priority threads are not running or waiting. This would tempt the programmer to run such a service thread at as high a priority as possible.
  
  MSDN documents advise:
  You should almost never use REALTIME_PRIORITY_CLASS, because this interrupts system threads that manage mouse input, keyboard input, and background disk flushing. This class can be appropriate for applications that "talk" directly to hardware or that perform brief tasks that should have limited interruptions.

  So the following factors may make it feasible to set the app to RealTime process priority. (I haven't tried these, they just seem plausible from the documentation.)

  • Set the application process priority to RealTime only infrequently as needed.  This is not a practical suggestion if polling hardware on a more-or-less continuous periodic basis (eg: once per few millisecs).
  • Run the app continuously at RealTime, but make sure that the main thread priority is set to Idle and/or the app is mostly blocked waiting for UI.

Scheduler Granularity

On what interval does the scheduler check the time, and take a look at the process/thread queue?   This will determine several items of interest to us:

• The minimum amount of time that we can expect our code to run before it may get swapped out.
• The increments of interval that our code may get swapped out for by competing threads or apps.
• The amount of time that a newly awoken thread may have to wait before getting a chance to be scheduled.
• The amount of time that a timeSetEvent callback function may wait after time is up before getting a chance to run.

Scheduler time-slice granularity (quantum)  is discussed in the System Internals references and elsewhere.  They report that, it's generally a multiple of 20 ms.  Here's the table, according to System Internals site:

Of interest:

• Note the dual function of the Boost setting -- to increase the foreground thread priority and increase the number of quanta that the running process gets each time.
• Note that the quantum size for NT Server is quite different than for Workstation!
• Needless to say, polling must be applied with some thought!

However, this misses some crucial points:

Setting Scheduler to High Res:  Scheduler granularity has some "normal" value, but can be set to a higher-resolution value by using the timeBeginPeriod and timeEndPeriod functions. Indeed, on a generic PC running W95 or NT4, it can be set to 1 millisec.

Scheduler Granularity Normally 10 millisec?  Contrary to what's written elsewhere, I found that the normal scheduler granularity appears to be 10 millisec, both in NT Workstation, and on Win95.  You can use my SkedGran demo app to see what you get.

Scheduler Period Regular?   Supposing that the scheduler is using 10 millisec periods, what happens if a thread finishes before its time slot is used up? Presumably the scheduler just checks the queue, assigning the next thread 10 millisecs, and so forth.  This means that the the times that the scheduler gets control will not necessarily be evenly spaced, often being 10 millisecs apart, but sometimes shorter.

Other Notes

1. Regardless of the millisec-level scheduling that you can get for your application code most of the time, under Win95 or NT you can't get it all the time.   This may be good enough for what you want to do -- but to evaluate this you'll probably need to build an app that monitors and reports how consistently your app's code gets scheduled in your target environment -- and reports on the distribution of delays that it sees.

2. Does code scheduled in a driver fare any better?  This presumably depends on how the scheduler shares time with drivers, and how driver priority works relative to application priority -- topics I haven't explored.  If someone has a brief explanation on this, let me know!

Sources

• MSDN Description (complete with nifty Java table of contents):
  • http://msdn.microsoft.com/library/sdkdoc/winbase/prothred_0n03.htm
  • In case MS moves the the document, there's a copy here.
• Related discussions at System Internals site
  • Frob:  Tool for tuning thread-time quantum
  • NT 5 Internals Preview:  includes discussion of thread time quantum
  • PMon: Thread monitoring tool.

[Up to:  Data Acquisition Topics]

Go to: