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
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
