[ntp:questions] Client doesn't drop failed source

David Woolley david at ex.djwhome.demon.invalid
Fri Jan 8 21:57:02 UTC 2010

Michael Moroney wrote:

> that synchronizes with the four clocks, and ntpq> peers shows one of the
> primaries with a "*" in the first column meaning it was synchronized to as
> time source, the other 3 show "+" as expected, meaning they are usable
> sources.  We disconnect the antenna of the selected clock.  As expected

* and + mean they are used, not just that they are usable.  The time 
used to discipline the clock is a weighted average of all of them.

> the clock (Spectracom) changes its stratum from 1 to 16 after a delay, and

> Now the question: For the next test, we disconnect the LAN cable of the
> selected primary clock, and we expect the next poll to fail and the client
> to give up on it and to select the other primary clock.  No, we just see 
> the time from the last poll incrementing well beyond the poll interval
> (1024 seconds) but the disconnected clock still selected as primary!

If it remains the best choice it could take up to 8192 seconds before 
all the samples are flushed from the FIFO and it becomes completely 
ineligible.  There is logic to discourage early switching, as clock 
hopping is, itself, considered a bad thing.

> When we connect the cable it fails over to the other primary.
> How do we get the system to fail over to another clock if the one it was
> using fails?  The system isn't a Unix (OpenVMS) it does use Unix type NTP
> commands/programs (ntpq, ntpdate, ntpdc)

As hinted at the beginning, except in terms of the stratum, root 
distance and root dispersion that it announces downstream, ntpd does not 
failover; it uses all the good clocks up to a, configurable, limit.

More information about the questions mailing list