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

Alan greigaln at netscape.net
Wed Jan 20 15:21:57 UTC 2010


Thanks for the reply,

I've checked and I have /usepmtimer in boot.ini and wclkres -p reports
Performance Counter Frequency: 3.580

I also have Cool N Quiet turned off in BIOS.

As an experiment I tried seeting affinity to processor 0 and retrying 
with the -M switch. No improvement - Jitter is at 100+ millseconds 
within a minute and the clock starts being regulaly stepped forward a 
few minutes later. With affinity set and without the -M switch I synch 
to within a few milliseconds with jitter of a few millseconds almost 
immediately. ALthough both offset and jitter jump up by about 20 msec 
depending on what I run but then settle down again as I expect under 
Windows without -M switch

Overnight (without the -M option) with the system idle and only running 
NTPD, both offset and jitter on all configured server clocks dropped to 
about 1 msec or less. Again even if the system is "idle" the time drift 
rate rockets as soon as -M is turned on.

Anything else I might look at?

Martin Burnicki wrote:
> 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




More information about the questions mailing list