[ntp:questions] Stick to PPS, even if the prefer server fails

David Mills 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 mailing list