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

Unruh unruh-spam at physics.ubc.ca
Fri Mar 27 17:40:53 UTC 2009

jra at febo.com (John Ackermann N8UR) writes:

>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.

The second would be trivial to apply. Just stick in a flag which gets set
once the initial external source has converged to within .1 sec say, and
if set it stays set and the PPS source gets used if it is set. If you
really worry, you could augment the flag everytime the prefer peer was
unavailable ( resetting it every time it was) and not use PPS if that
counter got greater than 86400 say ( one day)  This is about a three line
change to the atom driver. 

>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.

Use the shmpps code with the refclock_shm driver. It will wait until the
time source is reported to have an offset of less than .25 sec, and then
start the shm report of the PPS source. Thereafter it will continue to use
the PPS source as a normal source, which you can make the preferred source. 

More information about the questions mailing list