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

David Lord snews at lordynet.org
Mon Dec 2 14:49:26 UTC 2013


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.  The bug was seen on a
>> stable corporate LAN, of which I am now locked out of by the IT
>> Security Gestapo.
> 
> Huh, what have you done? ;-)
> 
>> I am no longer able to use your stable, or test your
>> developmental software at my workplace.  I also am no longer able to
>> provide constructive feedback on this software in this environment.
>>
>> 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.
> 
> Martin

I had maxpoll set at 10 when I first setup my network but sometimes
at that poll rate combined with daily temperature variations offsets
would gradually increase both in +ve and -ve directions. This could
clearly be seen in mrtg graphs. Solution was to reduce maxpoll to 7
or 8. I never thought of this as a bug. There was a daily variation
depending on season and a variation due to system load.

This has been with NetBSD 1997 to date and a period of a few years
when running FreeBSD. Currently NetBSD-6, ntp-dev-4.2.7p401, four
of the servers are in the pool.


David



More information about the questions mailing list