[ntp:questions] ntp-4.2.6p5 on Win 7 x64

Joe Gwinn joegwinn at comcast.net
Tue Jul 22 13:14:24 UTC 2014

In article <84lv9b-i5v.ln1 at ubuntu-server-1.py.meinberg.de>, Martin
Burnicki <martin.burnicki at meinberg.de> wrote:

> Nick wrote:
> > Brian
> >
> > thanks for your useful reply...
> >
> > On Fri, 18 Jul 2014 02:03:48 +0000, Brian Inglis wrote:
> >
> >> Windows is using the MM timer as its high precision time source, not PM
> >> timer, HPET or TSC.
> Huh, I didn't know (and I doubt) that NTP uses the MM timer as time source.
> Years ago there was a problem with NTP under Windows that the 
> interpolated system time used internally by ntpd got messed up when some 
> *other* program started to set the Windows MM timer to highest 
> resolution, e.g to play some multimedia stuff.
> As a workaround I submitted a patch to ntpd which lets the NTP service 
> itself set the MM timer resolution high when it starts, so there are no 
> more other effects on the interpolated time when some other application 
> also does so.
> The workaround comes in effect if the -M parameter is given on the 
> command line, and this is the default case for installations from the 
> Meinberg setup program.

Back in the day, video (and later audio) drivers were the culprit in
messing realtime up as well.  The drivers performed a hardware bus lock
of some kind during transfers.  This in addition to setting a very high
priority, and trumped anyone else setting high priority.  I never knew
the exact details, but it was one of many reasons why one does not use
Windows for realtime, unless one's idea of realtime is *very* relaxed. 
Although Windows has improved over the years, its latency still isn't
predictable enough for realtime of any stringency.  

Reliability is also an issue - the rule is that if one cannot tolerate
a forced reboot every few months or so, don't use Windows.  I know that
many Windows systems don't fall over nearly that often, but some do,
often for no known reason, and that's enough.  Only worst-case behavior

A typical architecture in my world is to use Linux or a RTOS like
VxWorks for the RT core, talking via UDP exchange over ethernet to a
Windows box housing the GUI.  Humans don't notice the timing burps, and
can reboot the GUI box as needed.

Joe Gwinn

More information about the questions mailing list