Article 2639 of microsoft.public.win32.programmer.kernel:
Thanks for the information Jamie. Does this also mean that the timestamp
of keyboard events by DirectX (DirectInput) under Windows NT 4.0 would
also be limited to roughly 15 msec (I'm using an Intel based PC, a
Pentium Pro at 200 Mhz)?


Jamie Hanrahan wrote:

> In article <343C4886.60A1@eeg.com>, behram <behram@eeg.com> writes:
> > Hi,
> >
> > I need to schedule an event in Windows NT 4.0 with a very fine time
> > resolution. For example, in my code I need to schedule some flag to
> be
> > set 200 msec from the current time, with a maximum error of +/- 4
> msec.
>
> NT normally runs the interval timer at an interval of 7.5, 10 or 15
> msec, depending on the platform.  This is the finest resolution
> available for things like waitable timers, or even the KeSetTimer call
>
> from kernel mode.
>
> If however you use a multimedia timer call with a resolution of
> anything down to 1 msec, NT will reprogram the interval timer
> accordingly so that your request can be implemented.
>
> It is not clear to me whether all timer requests subsequent to such a
> use of a multimedia timer (other than more multimedia timers) are then
>
> implemented with 1 msec accuracy.  But it's something to try.
>
> In any case, unless you do this the resolution of timer requests will
> *certainly* be no better than that of NT's normal interval timer
> (note, NOT the same as "quantum"!!!).
>
> > (without writing a kernel
> > mode driver to do the scheduling)?
>
> Even writing a kernel mode driver to do the scheduling won't get you
> any better resolution -- unless you have your own timer board to talk
> to.  KeSetTimer uses the same interval timer as the Win32 waitable
> timers and wait timeouts.
>
> > Roughly how accurate is the time scheduling in Win32 in NT?
>
> See above.
>
> There is another point to be aware of.  If you are waiting on, for
> example, a waitable timer, what happens when the timer comes due is
> simply that your thread enters the Ready state.  Whether it actually
> runs at that time or not depends on its priority with respect to the
> priorities of other Running and Ready threads.  i.e. on a one-CPU
> system,
> only the highest-priority Ready thread(s) gets to run, ever.
> Typically the higher-priority threads tend not to be compute-bound, so
>
> this isn't often a problem for long, but it can cause your
> timer-driven thread to not run as soon as the timer expires.
>
> On the other hand... if your thread becomes Ready at a higher priority
>
> than that of the Running thread, you can be assured that it will
> pre-empt the Running thread IMMEDIATELY.  This applies to all reasons
> for the thread becoming Ready, not just timer expiration.  The Running
>
> thread does not have to use up its quantum interval before it can be
> pre-empted.
>
>         --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
>         Internet: jeh@cmkrnl.com (JH645)  CompuServe: 74140,2055
> drivers, internals, networks, applications, and training for VMS and
> Windows NT
> NT driver FAQ, links, and other information:  http://www.cmkrnl.com/
>
> If you post a reply in news, please don't e-mail it too.