[ntp:questions] Stick to PPS, even if the prefer server fails
John Ackermann N8UR
jra at febo.com
Sun Mar 29 17:00:21 UTC 2009
It's the concept of requiring a single prefer peer in the case where the
PPS signal doesn't provide its own timecode.
Both my LORAN-C and my Cesium sources provide PPS without accompanying
timecode (they are on different servers, so this isn't the multiple-PPS
problem). I have to pick another server to be the prefer peer for each.
If that server fails, the PPS signal is ignored, even if the PPS is
still valid, and even if the PPS is still within a sane value of the
other servers in the selection set.
Most people have a refclock that provides both PPS and timecode, and in
that case treating the two together makes perfect sense. But that's not
the case I'm concerned about.
David Mills said the following on 03/29/2009 12:37 PM:
> The intersection algorithm has been documented in several places along
> with configuration controls to modify its behavior. Is the tyranny you
> cite due to that algorithm or the notion of the prefer peer in the first
> place? If the latter, do you have an alternate suggestion?
> John Ackermann N8UR wrote:
>> David Mills said the following on 03/28/2009 11:12 PM:
>>> 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.
>> Dave, I fully agree with you that the PPS signal should be subject to
>> the selection algorithm. It's the tyranny of the prefer peer that I
>> object to.
> questions mailing list
> questions at lists.ntp.org
More information about the questions