On Wed, Sep 28, 2011 at 16:09, David J Taylor <[email protected]> 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: http://msdn.microsoft.com/en-us/library/ms724394(VS.85).aspx 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. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
