[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