Brian Inglis wrote:
Never had a problem keeping within a few ms offset from UTC with only good network sources, Windows 7 x64, and NTP 4.2.6p5 stable.
As far as I have seen this may depend. On some systems it works, on others it doesn't which means the time synchronization doesn't settle.
I've seen systems where the residual offset and jitter reported by "ntpq -p" was continuously more than 1000 ms, and except for very rare cases where a problem with the mainboard or some other driver could be identified to cause these problems the resulting time accuracy could be increased to a few milliseconds or so after a developer version with the 16 tick workaround had been installed, and the polling interval has been limited.
I'm not sure if the reason whether it works or not is whether the undisciplined system time runs fast or slow, in which case the time adjustment relative to the standard adjustment has to be decreased or increase.
This could cause different computations in ntpd's algorithms which compute the adjustment as well as in the Windows kernel which evaluates the adjustments.
With the same platform plus a Garmin 18x LVC, stays within +/-60us offset, average +/-0.5us, s.d. < 15us; jitter < 50us, average < 20us, s.d. < 5us.
Haven't tried similar hardware refclock and eventually PPS under Windows myself, but I'd expect this works much better since AFAIK refclocks are in general polled in shorter intervals, at least in newer versions of ntpd.
Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
