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 |