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

Martin Burnicki martin.burnicki at meinberg.de
Wed Jul 23 14:19:33 UTC 2014

Joe Gwinn schrieb:
> 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
> matters.
> 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

I absolutely agree.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list