[ntp:questions] Re: ppspeer and prefer
gnu at wraith.sf.ca.us
Thu Dec 23 04:46:05 UTC 2004
David L. Mills wrote:
> 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.
Yes; I did not intend to suggest a change to this operation of prefer.
> 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.
I knew that my usage was bogus in my configuration, but I was in a quandry
as to how to associate a pps signal with a reference clock, without also
marking the reference clock as "prefer."
> 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.
Well, I've built freebsd with two pps sources--it worked fine with
one lit up. I can test here with such a config, using two pps sources,
specifically a wwvb/pps and irig-b/pps combination.
My theory here, is that each of these pps signals would be less prone
to serial port or audio card induced jitter, on their associated
reference clock. However, the only way to light up these pps sources,
is to have a "prefer," which is my quandry, there is only one "prefer"
allowed. So, I am asking, how can I "turn on" and associate these
respective pps signals, with their pertinent reference clocks? It seems
I can't, at the moment, or at least I am not able to figure out how,
when trying to run two pps sources and their reference clocks on
the same host. That is what I was trying to say with my "ppspeer"
Maybe the real answer is to "atomize" these drivers, so that they
timestamp in the fashion of the GPS_NMEA reference clock? That would
leave alone all the existing mechanism for "prefer." This would
work for the serial WWVB, but begs the question for IRIG-B (audio).
Mostly the Spectracom clock and the Datum IRIG-B time code unit have these
nifty PPS signals available, and I would like to put them to use,
with the idea that I get better chime in this fashion.
> 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.
I have done exactly this, and it works great, when all you have is a
single pps source.
> 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.
More information about the questions