[ntp:questions] Stick to PPS, even if the prefer server fails
John Ackermann N8UR
jra at febo.com
Sat Mar 28 23:26:07 UTC 2009
Kevin Oberman said the following on 03/28/2009 06:53 PM:
> Ideally, if the source of the time being trained by the PPS is bad, the
> PPS also should be considered bad and kernel PPS should be disabled.
This should only be the behaviour for a refclock that provides both a
PPS and a timecode. If it has a PPS only, this results in lower
reliability because the PPS could be just fine while the independent
prefer peer goes insane.
John
More information about the questions
mailing list