[ntp:questions] NTP Bug 2328 - Vista/Win7 time keeping inaccurate and erratic

David Taylor david-taylor at blueyonder.co.uk.invalid
Thu Nov 28 12:30:15 UTC 2013


On 28/11/2013 09:31, Martin Burnicki wrote:
> 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

Thanks for your comments, Martin.

Yes, I worked with Dave Hart on testing the changes to NTP for the new 
Windows API, and one Win-8/32 PC I have running over Wi-Fi shows very 
significantly better offsets than similar PCs running under Win-7.  Even 
over Wi-Fi averaged jitter is around 100 microseconds, increasing to 200 
microseconds during this morning's download and install of .NET 4.5.1.

I'm not sure whether we still have a route into Microsoft to get the 
adjustment quantisation fixed - it would certainly be helpful.

Referring to your graphs, I took a GPS/PPS synced Raspberry Pi along to 
the downstairs network, and made Win-7/64 PC Molde take its preferred 
reference NTP server instead of an stratum-1 server over Wi-Fi.  What a 
dramatic improvement!

   http://www.satsignal.eu/mrtg/molde_ntp-b.html

Averaged jitter has dropped from around 3 milliseconds to just under 1 
millisecond (likely a Win-7 resolution limitation), and the offset from 
a spikey +/- 5 milliseconds to a much smaller value as can be seen from 
the graph.  Now I have to think about installing Ethernet cable 
everywhere!  <G>

All the Windows non-stratum-1 PCs can be compared here:

   http://www.satsignal.eu/mrtg/performance_ntp.php#windows

-- 
Cheers,
David
Web: http://www.satsignal.eu



More information about the questions mailing list