[ntp:questions] ntp-4.2.6p5 on Win 7 x64
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.
More information about the questions