[ntp:questions] Re: ppspeer and prefer
David L. Mills
mills at udel.edu
Thu Dec 23 00:54:27 UTC 2004
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.
> 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
> 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
> 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
> 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.
More information about the questions