[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Mon Dec 2 16:24:53 UTC 2013

On 2013-12-02 05:02, Martin Burnicki wrote:
> Ed,
> Mischanko, Edward T wrote:
>> Martin,
>> Reading your reply, it sounds like you understand and somewhat
>> confirm this bug.
> I *think* I have observed something like this some time ago.
>> I agree this may be a Windows XP only bug.
> I'm not sure whether it is. We'll have to find this out, but this can be very time-consuming.
> We need to test both ntpd-stable (4.2.6p5) and ntpd-dev (4.2.7p???) both under Windows XP and Windows 7.
> Under Win XP both ntpd-stable and ntpd-dev should converge fine at low polling intervals. We need to know if one of them or both are still stable when the polling interval increases beyond 7.
> Under Win 7 ntpd-dev should also converge fine at low polling intervals, so another test could find out if it also stops to converge when the polling interval ramps up beyond 7.
> ntp-staple might converge under Win 7, or not. If it doesn't at low polling intervals then it makes no sense to see what happens if the polling interval ramps up, if that happens at all.
> Since this seems to happen under Windows only, the reason could be some calculation error or overflow, and it can have been unintentionally fixed or introduced between ntp-stable and ntp-dev.
> So IMO we first need to find under which conditions this occurs, then we can try to find a bug in the source code.
>> I have not the ability to confirm this bug on newer versions of
>> Windows or newer versions of NTP at work.

>> At home, I found all the FreeBSD and Windows, XP and 7, ports to be
>> unstable in the WAN / Internet environment.
> Hm, if even the FreeBSD version is unstable I'd say this is due to you network environment or configuration.
> As said above, a reliable test should first make sure that proper synchronization is possible, i.e. with a stable network connection and a good upstream NTP server.
>> NTP polling increases
>> regardless of offset and NTP appears not to keep up or sync the
>> clock.  I have not observed any over-regulation that is feared with a
>> shorter polling interval.  My primary goal is to have the smallest
>> offset as possible; after that goal is met, I can worry about clock
>> jitter.  Is that the goal of NTP?  If so, it is not working in the
>> 100% network environment, with no PPS reference server use, and
>> default software settings.
>> I would be happy to answer specific questions if my observations are
>> still not fully understood.
> I've just set up some tests with XP/ntp-stable and Win7/ntp-dev to see how it gores and if I can confirm this bug.

When I ran current stable under Win 7 with only network servers I found
I had to drop minpoll to 4 (default is 6) so iburst would quickly get
a good offset and pull drift down from initial out-to-lunch estimate
compared to drift file contents.

Once drift got pulled down close to hardware levels, poll would increase
and further pull down offset < 10ms, then at longer poll intervals,
both drift and offset would slowly get more accurate over a period of
about three weeks.

About then patch Tuesday would come around and it would be back to square one!

I had to ensure BIOS spread spectrum and OS power saving were turned off
and pick servers that were not busy, with no drops or steps, delay < 90ms,
jitter < 20ms, offset < 10ms.

As pings were often blocked, I used traceroute (tracert on Windows) to do
initial delay estimates, when those were not also blocked in a DMZ, and
tried ntpq -p -c rv -c cv as a final check out when possible.

I try to pick about four good quality servers which may be quite distant,
but within the criteria above, and four decent fairly local servers for
those times when interconnects fail and only local servers are reachable.

One thing I have noticed is that my NTP clock (HPET) is being reported
as having ~28PPM drift where my hardware is only ~.9PPM!

Take care. Thanks, Brian Inglis

More information about the questions mailing list