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

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
to:
  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).

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

_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions

Reply via email to