[ntp:questions] Stick to PPS, even if the prefer server fails
martin.burnicki at meinberg.de
Fri Apr 3 20:42:36 UTC 2009
> You mean the cdma clock will continue to deliver a PPS signal running it
> off an internal drifting clock? A PPS is simply a pulse every second. How
> does it deliver the information that it is bad? Or you know it is bad
> because it starts to drift with respect to other clocks you trust more?
> And why do you trust them more?
If you look at this from the refclock's point of view this may make sense.
If the refclock starts up the time is not synchronized, and the PPS output
may be disabled. After the refclock has synchronized to its time source,
e.g. the GPS sats, status changes to synchronized and the PPS output is
If the refclock *then* fails to receive the satellites the internal timing
is not immediately bad since many refclocks provide an oscillator which is
magnitudes better than the cheap chrystal in a PC. If the refclock
additionally tells its "time consumer" (ntpd or whatever) via some status
flags that it has lost synchronization the the "time consumer" can decide
whether to still accept the refclock plus PPS as time source, or not.
The now unsynchronized refclock may still be accepted if no other reliable
time source is available, and may be discarded if there's a better time
Configuration of this could be simplified using the proposal in my other
post, i.e. assign a refclock's pseudo UIP to a PPS source instead of
marking one refclock as "prefer".
BTW, this is also how ntpd itself works. If an ntpd node syncs to an
upstream time source it declares itself as synchronized with a good
stratum, depending on the stratum of the upstream source. After the
upstream source has become unreachable the ntpd node keeps claiming to be
synchronized, at least as indicated by the leap bits, and it also keeps its
stratum, at least if no other time source has been configured which is
More information about the questions