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 _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
