[ntp:questions] Stick to PPS, even if the prefer server fails
mills at udel.edu
Sun Mar 29 03:12:54 UTC 2009
The intended design to detect and suppress bad reference/PPS clocks is
at least two additional sources, that do not have to be reference
clocks. If the reference/PPS clock sails to the sunset, the selection
algorithm will vote it off and the PPS will follow. The server will
continue at whatever surving source stratum plus one. This might not be
considered pefect, but it would avoid real disaster.
John Ackermann N8UR wrote:
>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.
>questions mailing list
>questions at lists.ntp.org
More information about the questions