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 sub-microsecond resolution.
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.
Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
