[ntp:questions] Re: ppspeer and prefer

David L. Mills mills at udel.edu
Thu Dec 23 00:54:27 UTC 2004


Steven,

You are stretching the intended semantics. There is one and only one 
function of "prefer", that is to prevent an association from discard by 
the clustering algorithm and using only its offset in the combining 
algorithm. In principle, that applies to the PPS association as any 
other association, although I can think of no circumstances where that 
would be useful.

The PPS signal from a preferred radio is the best choice on the 
assumption that, if something goes wrong with the radio, its PPS source 
is suspect. So, the PPS signal is discarded if the prefer peer has come 
falsetick or unreachable or its offset is greater than the step 
threshold. That last is to prevent a step when the PPS signal takes over.

The code was not intended to deal with more than one prefer association 
(which one would you use for the combining algorithm?). As it happens, 
if prefer is used for multiple associations, neither can be discarded by 
the clustering algorithm, but only the last one marked will be used in 
the combining algorithm.

Like you, we have multiple receivers, breakout panels and awesome server 
farms. We often connect more than one receiver to a server, but only one 
of them is designated prefer and the PPS signal is always from that 
receiver. If that radio dies, so does its PPS signal. Different servers 
intentionly use PPS signals from different radios and in each case only 
the associated radio is marked prefer.

The best way to deal with your intended semantics, should the effort to 
implement it be justified, is to provide multiple PPS signals, each 
associated with a different radio. A multiple-PPS kernel was once 
implemented for the Alpha and proved to work, but that code along with 
the Alpha is a lame duck. If such an implmentation were to quack in 
FreeBSD, for instance, we should revisit the issues.

There bottom line is prefer only the radio or network peer that reliably 
numbers the seconds counted by the PPS signal. For instance, when using 
an Internet source to number the seconds and a cesium clock to split the 
seconds, prefer only the Internet source.

Dave

rtxo wrote:
> 
> Hi Folks--
> 
> Currently, when using a PPS capable device, ntpd must configure a 
> "prefer" peer so that
> the daemon will recognise and utilise the PPS timing.
> 
> Now, I have a couple sources of PPS (IRIG-B and a WWVB clock) but would 
> rather have
> the GPS be "preferred" as it is the highest quality of time at this 
> facility.
> 
> This makes for a minor problem, in that it seems risky to "prefer" the 
> GPS when
> it may well be that the WWVB, say, is bonkers, thus causing its PPS 
> signal to
> chatter. However, I must "prefer" *something* or else lose access to the
> generated PPS timing signals. Currently my (bogus) scheme is to have two
> "prefer" statements. This (cough) "works" but I doubt ntpd was really 
> intended
> to be operated in this fashion.
> 
> So, I'm wondering if it is worth having a "ppspeer" configuration 
> command, that will
> act to light up a reference clocks associated PPS signal, while keeping the
> existing "prefer" in place.
> 
> It might be in the form of an identifier command, perhaps of the 
> reference clock
> ID, so that, say, WWVB unit 0, has its associated PPS configured as 4-0,
> WWVB unit 1 PPS as 4-1, etc. No identifier falls back to existing behavior,
> thus preserving compatability.
> 
> Background: I have a "fanout box" that provides GPS to all my servers. I 
> plan
> to have additional clocks, such as the WWVB and IRIG units, as backups. The
> WWVB will possibly get its own fanout box as well since this scheme works
> so well with the GPS (NMEA) driver and ntpd.
> 
> ../Steven




More information about the questions mailing list