[ntp:questions] NTP server not reducing polling interval on upstream hosts
michael at talosis.ca
Fri Oct 17 10:10:08 UTC 2014
On 16 Oct 2014, Rob wrote:
> Phil W Lee <phil at lee-family.me.uk> wrote:
> > The problem I am having is that it is stuck on polling the upstream
> > stratum 1 servers it uses as a sanity check every 64 seconds. (it's
> > main source is a Garmin GPS 18x with PPS, based on the excellent
> > guides by David Taylor and Ryan Doyle).
> It is a wellknown bug...
ISTR this being discussed before, with someone (probably Mills himself)
proclaiming that the behavior is actually correct. He said while he
didn't *explicitly* program ntp to force all clocks to the shortest
polling interval any of them needs, the requirement to do so was actually
implied by the specification, and the algorithms he did explicitly
program were clever enough to figure that out before he did.
An approximate, more human-understandable, argument for it was that if
you are polling outside sources every 1024 seconds and one special clock
every 64, then should that special clock turn falseticker, it gets 15
polls to pull the system time far off course before ntp has a chance to
notice that the other clocks fail to agree.
However I posted much the same thought over two years ago, and also
pointed out two holes in the argument, with no one posting a defense in
the interim. The first is that polling at 64 isn't enough to stop an
excursion under bad PPS, and the second is that reference clocks aren't
likely to falsetick.
---- Michael Deutschmann <michael at talosis.ca>
More information about the questions