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

David Taylor david-taylor at blueyonder.co.uk.invalid
Tue Nov 26 08:55:37 UTC 2013

On 25/11/2013 14:36, Martin Burnicki wrote:
> If you are encountering problems getting the Windows time adjusted
> properly by ntpd then a a Windows bug can be the reason why.
> Some Windows versions don't apply small time adjustments to the system
> time at all. For example, if NTP applies an adjustment less than 16
> ticks to the Windows time this is simply ignored by Windows. However,
> NTP expects the adjustment to have some effect, but if there is no
> effect then the next time comparison yields a much larger difference
> than expected, and thus causes another adjustment which is probably
> larger than necessary. As a summary this can cause large swings in the
> time adjustment values.
> A developer version of the NTP package contains a workaround for this
> Windows bug. The report and fix are discussed here:
> NTP Bug 2328 - Vista/Win7 time keeping inaccurate and erratic
> https://bugs.ntp.org/show_bug.cgi?id=2328
> The bug report contains a link to the Microsoft support web page
> explaining the bug:
> SetSystemTimeAdjustment May Lose Adjustments Less than 16
> http://support.microsoft.com/kb/2537623
> Even though the MS report only mentions Windows 7, the Windows Server
> 2008 kernel is similar to Windows 7 and has probably the same bug. So if
> you want to give it a try you can download a developer version of the
> NTP package which includes a workaround here:
> http://support.ntp.org/people/burnicki/windows/
> You should try the release version first. Just unzip the ZIP archive,
> stop the NTP service, copy all extracted files over the files in your
> NTP installation directory (e.g. C:\Program Files (x86)\NTP\bin\), and
> restart the NTP service.
> Also all newer development versions of the NTP binaries should include
> this.
> We have found that this version has greatly improved the resulting
> accuracy on Windows 7 and Windows Server 2008 installations.
> Please note under Windows you should configure all upstream servers with
> a line reading
> server aa.bb.cc.dd iburst minpoll 6 maxpoll 6
> where aa.bb.cc.dd has to be replaced with the host name or IP address of
> your NTP server.
> Please don't use polling intervals below 6 with the developer version
> since this prevents the workaround from working correctly as discussed
> in the bug report.
> Hope this helps.
> Martin


Just for interest, following your remark about smaller polling 
intervals, I changed three PCs on my working system from:

   server aa.bb.cc.dd iburst minpoll 5 maxpoll 5
   server aa.bb.cc.dd iburst minpoll 6 maxpoll 6

and in all cases the performance was no better when measuring the offset 
or the jitter.  All PCs synced to several stratum-1 servers (one 
FreeBSD, three Windows), and all using NTP development version 4.2.7p398.

Win-7/32 Netbook PC Ystad, Wi-Fi synced.  Averaged jitter unchanged at ~ 
1 millisecond, offset visibly worse with somewhat greater transients.

Win-7/64 Intel Atom system PC Molde, Wi-Fi synced.  Averaged jitter 
worse, changed from ~2.5 milliseconds to ~5 milliseconds, offset visibly 
worse with noticeably greater transients.

and, just for comparison:

Win-8.1/32 portable PC Bergen, Wi-Fi synced.  Averaged jitter changed 
from 0.1-02. milliseconds, to 0.4 milliseconds.  Offset variation 
similar, and offset stayed within 0.25 milliseconds (Windows 8 has more 
accurate time function calls).

Web: http://www.satsignal.eu

More information about the questions mailing list