[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