[ntp:questions] Timekeeping broken on Windows XP with multimedia timer enabled (-M option)

Martin Burnicki martin.burnicki at meinberg.de
Wed Jan 20 14:23:29 UTC 2010


Alan wrote:
> I downloaded the latest prebuilt binary from Meinberg (4.2.4p4)and
> installed on XP Service Pack 3. NTPD was not only completely unable to
> keep the clock in synch but actually made things far worse with time
> drifiting backwards by up to a second every few minutes and NTPD
> continually stepping the clock forward with the "exceeds 500ppm message".
> 
> I then downloaded the pre-built 4.2.6 from Dave Harrt's site and it did
> exactly the same. Then I tried turning off the "-M" option and
> restarting (both versions). The clock quickly achieved synch to within a
> few milliseconds. The drift frequency was calculated at 4.764 (rather
> than above 500) and the jitter reduced to a few milliseconds. Now when I
> run certain applications the clock jumps by a few millseconds (which the
> -M option is supposed to cure but I can live with this under windows)
> but my question  is why is NTPD broken in my environment when installed
> withe the default Meinberg installation option of setting the timer to
> highest resolution? Anyone else seen this?
> 
> This on a dual core AMD-64 with WIndows XP Professional fully patched.

By default Windows has a time resolution of 1 timer tick interval only, i.e
about 16 ms with Win XP.

The reference implementation of NTP uses the Windows QueryPerformanceCounter
(QPC) API call to interpolate the time between 2 timer ticks. 

The QPC API is implemented in the Windows Hardware Abstraction Layer (HAL)
and uses one of the timers provided by the mainboard and/or the CPU.

If the QPC call works based on the CPU's timestamp counter (TSC) registers
then the value of the current timestamp taken depends on the CPU core on
which the code is executed.

On many types of AMD dual core CPUs the timestamp counters in the individual
cores are not synchronized, so if a piece of code runs alternating on
either CPU core the resulting timestamps may not be consistent, and
computations based on those time stamps yield faulty results.

Also, changes in the CPU clock frequency by AMD's Cool'n'Quiet or Intel's
Speedstep can mess up the QPC results.

A workaround can be to add the USEPMTIMER switch in the boot.ini file. See:

Explanation for the USEPMTIMER switch in the boot.ini
http://blogs.technet.com/perfguru/archive/2008/02/18/explanation-for-the-usepmtimer-switch-in-the-boot-ini.aspx

This forces the QPC API to work using the power management (PM) timer
provided by the mainboard's chipset instead of the CPU's TSC registers.

AFAIK this boot switch should have been set by some XP service pack, but you
may want to check whether this is really the case.

I've written a little tool which can reports clock frequency for the QPC
API:
http://www.meinberg.de/download/utils/windows/wclkres-1.2.zip

Unpack the ZIP archive and run the command

wclkres -p

in a command line window. Please let us know which Performance Counter
Frequency is reported by the command. If the PM timer is used then the
frequency should be about 3.58 MHz. If the frequency matches the CPU's
clock frequency then the CPU's TSCs are used which may cause such bad
behaviour.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list