[ntp:questions] Stick to PPS, even if the prefer server fails
mills at udel.edu
Fri Mar 27 20:26:12 UTC 2009
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
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.
David Woolley 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
More information about the questions