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

David Mills mills at udel.edu
Fri Mar 27 20:26:12 UTC 2009


David,

True; this is an instance of the Principle of Fate Sharing. There is a 
long history over 23 years when something like a faulty antenna caused 
the serial timecode and PPS signal  to wander away from each other 
resulting in a large number of clients to jump the second every few 
hours. There were occasions when faulty PPS house wiring resulted in 
similar behavior. Keep in mind the following.

1. There are as many sanity checks as the timecode permits. The NMEA 
interface provides very little health information, but our Spectacom, 
Austron and Arbiter receivers provide much more useful information which 
the drivers do interpret.

2. The PPS signal is groomed with a range gate to remove spurs that 
might be picked up in the house wiring and to prevent chaos if the PPS 
is connected to an incorrect source or has failed for some time (all of 
which have happened here on more than one occasion).

3. The PPS is purposefully  ignored if the preferred source does not 
survive the intersection algorithm or the prefer peer offset is greater 
than 0.4 s. Ponder on this and consider the failure scenarios if this is 
not done.

 I would assume any other method to capture the PPS signal does much the 
same thing for the same reasons.

Now consider the case with two or more flakey timecode receivers or even 
external servers are involved together with one or more disciplined PPS 
sources. First, you have to understand a cesium clock is not really a 
clock; the PPS function involves a counter/divider that must be 
calibrated. Once upon a time I had three of these animals that required 
regular trips to USNO in Washington, DC. Upon arrival, a lab techician 
would come to the van towing a cable that plugged into the clock. Then, 
he pushed a button to synchronize the clock PPS to USNO PPS. To conform 
to hazmat regulations we could not use the Baltimore tunnels; we had to 
use the Annapolis bridge.

The point made here is that, if you need to go to the trouble and hazard 
of a real cesium farm, you are already running serious infrastructure 
and it probably doesn't make much sense to duplex the PPS source. In our 
case when we calibrate a clock, we simply unplugged the PSS and plugged 
it into another clock. However, if for other reasons you need multiple 
PPS sources, read on.

Once upon a time there were three different PPS interfaces and three 
flavors of Unix tty interfaces and it got seriously complicated to 
support all combinations. So, the Digital guys and I rammed the PPSAPI 
interface down your collective throats. The mission in that adventure 
was to hide the interface issues in the ppsclock.h header file specific 
to each architecture. The version used with Solaris supports only one 
PPS abstraction, but the version used with FreeBSD should support more 
than one. I have no idea whether Linux does or does not.

The prefer peer issue is richly contentious and probably overstated. 
There is indeed only one prefer peer at a time, but there can be more 
than one peer so designated. If so, the first one in the configuration 
file that passes all sanity checkes becomes preferred. The engineering 
abstraction is that the PPS signal appears to come from the prefer peer 
and inherits its other characteristics like stratum, distance, etc.

There is now way I can imagine how to discipline a herd of PPS signals 
other than to associate each one separately with the associated 
seconds-numbering source. One possible way is to use the unit number 
with the expectation that the unit number of the reference clock is 
associated with the atom driver with the same unit number.

Dave 

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.
>
>_______________________________________________
>questions mailing list
>questions at lists.ntp.org
>https://lists.ntp.org/mailman/listinfo/questions
>  
>




More information about the questions mailing list