[ntp:questions] NTP Bug 2328 - Vista/Win7 time keeping inaccurate and erratic
martin.burnicki at meinberg.de
Thu Nov 28 09:31:03 UTC 2013
David Taylor wrote:
> I wish I could say it was all fixed in Windows-8, but it /is/ better there.
Windows 8 supports a new API which provides the system time with
If I remember correctly then Dave Hart has already implemented some code
in ntpd-dev some time ago which uses this API, if it is available.
This should allow ntpd to compute the difference between the system time
and some reference time very accurately, without requiring interpolation
between timer ticks or similar tricks. This is a precondition for
accurate synchronization of the system time.
On the other hand, as far as I know, there is no new API to apply
adjustments to the Windows system time more smoothly. The legacy API
only allows to specify to change the amount of time (in 100 ns units)
which is added to the system time at every 15.6 ms interval.
I.e., the standard value is 156000, and the clock drift can be changed
by setting the value to 156001 or 155999. Even these steps are often too
coarse, so ntpd provides a kind of PWM control which increases the
adjustment value. E.g. if the required drift compensation is only half
of what is gained by a +1 increment then ntpd increments the tick
adjustment for a certain interval, and then decrements it for the same
interval, resulting in a mean value of +0.5.
Things are even worse if the Windows kernel ignores small adjustments
below 16. In this case the time synchronization software had to change
the tick adjustment from 156000 to 156016 or 155984 to cause some effect
in system time keeping, so the PWM control has to account for this. E.g.
and apply +16 for a given interval, and then use the original value for
31 * the same interval to get a mean value of +0.5.
In 31 times of a given interval the clock can drift much more than
during a single interval only.
In the lower parts of the graphs I've recently posted you can see how
ntpd applies corrections to change the clock drift.
I don't know if Windows 8 also ignores tick adjustments less than 16, as
Windows 7 does, but this would probably result in decreased performance
of the time adjustment accuracy again, and thus limit the advantages
provided by the new API.
More information about the questions