[ntp:questions] Windows TimeIncr value

Dave Hart hart at ntp.org
Wed Sep 28 16:54:21 UTC 2011

On Wed, Sep 28, 2011 at 16:09, David J Taylor
<david-taylor at blueyonder.co.uk.invalid> wrote:
> Folks,
> While trying to debug an "NTP stops working" problem on Windows, I have
> found that the TimeIncr value for that system is 156000, rather than the
> 156250 normally expected.  I appreciate that there are a number of different
> values which may be seen but I don't find both 156250 and 156000
> sufficiently different to be one of the "usual" values.  The PC is seeing an
> error of about 1 second in ten minutes, which is about the difference
> between 156250 and 156000.  It's as if something has changed the default
> TimeIncr for that PC, and changed it permanently.  I couldn't find the value
> in the registry, so I wonder whether it's hard-coded in one of the system
> files.

To provide a little more context for those not elbow-deep in Windows
timekeeping, David is referring to the nominal length of the system
clock tick reported by Win32 API GetSystemTimeAdjustment:


This API works in units of 100 nanoseconds (1e-7 s).  By far the most
common value observed is 1e7 / 64 = 156250, exactly 1/64th of a
second.  The value is not coming from the registry, but from the
particular HAL DLL (Hardware Abstraction Layer) Windows is using for
the system.  In the past, or with sufficiently old systems, one would
occasionally see systems with 100 Hz software clocks, reporting 1e7 /
100 = 1e5 = 100000 hundred-nanosecond units nominal tick length.  It
is extremely rare for changing HAL to be appropriate, typically there
is only one suitable option and Windows installation determined which.

ntpd on Windows logs this value at startup:

7 Sep 13:50:55 ntpd[2224]: Clock interrupt period 15.600 msec

That machine is a Dell Inspiron 9400 running Windows Vista.  It has
the latest BIOS firmware and windows updates.  Despite repeated
attempts using NTPD_TICKADJ_PPM, I've never been able to tame its
clock meaningfully.  I believe the problem is spread-spectrum CPU
clocking that cannot be disabled, but that's not confirmed.

On the one hand, a reported tick of 15.600 msec (156000) isn't unheard
of, but I can't point to a system using that value where ntpd behaves
well, either.

Dave Hart

More information about the questions mailing list