[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