[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7
Mischanko, Edward T
Edward.Mischanko at arcelormittal.com
Mon Dec 2 03:01:08 UTC 2013
Reading your reply, it sounds like you understand and somewhat confirm this bug. I agree this may be a Windows XP only bug. 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. 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. 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.
From: questions-bounces+edward.mischanko=arcelormittal.com at lists.ntp.org [questions-bounces+edward.mischanko=arcelormittal.com at lists.ntp.org] on behalf of Martin Burnicki [martin.burnicki at meinberg.de]
Sent: Tuesday, November 26, 2013 9:22 AM
To: questions at lists.ntp.org
Subject: Re: [ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7
Brian Inglis wrote:
> On 2013-11-25 07:36, Martin Burnicki wrote:
>> Also, if you don't limit the upper bounds of the polling interval by
>> "maxpoll 6" you may run into this bug:
>> NTP Bug 2341 - ntpd fails to keep up with clock drift at poll > 7
> Interested to see this mentioned but not seen it or reports elsewhere.
> This does not appear to be a problem in current stable with remote network
The bug report is for ntp 4.2.7, i.e. the developer version, so this may
not occur with the current stable version, which is 4.2.6p5.
As far as I I think I have seen a NTP configuration where the polling
interval ramped up, and the control loop didn't settle anymore.
However, this may depend on the NTP software version, this may only
happen with the Windows port only, and it may depend on whether the
undisciplined oscillator is slow or fast, i.e. on the sign of required
> At long poll intervals, the FLL drives the frequency close to the hardware
> rate, and the offset follows down from ms to us levels.
This is probably correct as long as the oscillator is stable during the
poll intervals. However, my observation is that usually the Windows
system time is disciplined more accurately with short polling intervals,
at least under Windows.
So my advice would have been to use minpoll 4 maxpoll 4, if this setting
wouldn't affect the workaround implemented in -dev.
> With current stable and a ref clock with prefer or low poll, and backup
> servers with low or no minpoll, backup servers are polled at minpoll or
> the same rate as the ref clock, so would never see this issue.
Hm, are you really sure the polling interval for the backup server(s)
depends on the polling interval of a configured refclock? I haven't
noticed this, yet, but I also haven't checked this.
What if you don't have a refclock, only upstream servers?
> Could this be solved by setting poll or prefer on a ref clock, as
> recommended for best results?
As said above, I think most installations on Windows don't even have a
refclock, so I prefer simply to add the minpoll/maxpoll parameters to
the server line(s) specifying the upstream server(s).
> Should NTP even be expected to take care of this automatically?
If it turns out that the problem described in bug 2341 is real, then the
best solution would be to fix this. I'd expect this is simply some kind
of range overflow or similar, which only happens under certain conditions.
If the reason for this problem could not be located in the code then a
workaround could be to limit maxpoll to 7 or so by default.
Anyway, in my experience everything works best under Windows if maxpoll
is as small as possible, i.e. 6 with the restrictions implied by the
workaround for the Windows bug.
questions mailing list
questions at lists.ntp.org
More information about the questions