[ntp:questions] Stick to PPS, even if the prefer server fails
John Ackermann N8UR
jra at febo.com
Fri Mar 27 12:15:38 UTC 2009
David Woolley wrote:
> Unruh wrote:
>
>> I have now looked at the refclock_atom source and indeed, it demands that a
>> prefer clocksource is available, and ignores the PPS if it is not. This I
>> believe is a bug, or at least a design infelicity. You could either hack
>
> I suspect the reasoning may be that both normally come from the same
> radio clock which will free-run the PPS when it loses a signal, so that
> detecting the failure of the NMEA data is the only way of telling that
> the PPS data is unreliable.
More than that, some PPS sources don't have an accompanying timecode, so
they need another source to provide the coarse time. This does cause
some interesting design challenges because it makes the PPS reliant on
an external source.
A couple of years ago I tried defining multiple prefer peers to improve
the reliability, but never got that working in a reliable way.
I'd like to see one of two solutions: (a) the ability to define
multiple prefer peers, such that failure of one would cause a switch to
another; or (b) an option that would require an external sane source for
initial sync, but once the time is known to the second, continue relying
on the PPS even if the prefer server goes away.
BTW -- this is a real-world issue, at least for my definition of
"world". Two of my NTP servers have this problem. One syncs from a
Cesium atomic clock, and the other from a LORAN-C receiver. Both those
sources provide PPS but no accompanying timecode.
John
More information about the questions
mailing list