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
http://bugs.ntp.org/show_bug.cgi?id=2341
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
servers.
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
the adjustments.
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.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
