[ntp:questions] Re: ppspeer and prefer
David L. Mills
mills at udel.edu
Thu Dec 23 21:02:41 UTC 2004
In the intended failure/recovery model it doesn't make sense to
associate a PPS signal with anything but the source that numbers the
seconds. Aside from the current behavior of the code as described in my
last, there is no provision to support more than one PPS/source
combination. Should you choose to "atomize" the driver as the NMEA
drivers do, you lose the median filter/trimmed mean grooming without
which you can't reliably split the microsecond.
Should you discover that FreeBSD does support more than one source in
the PPSAPI, you can certainly light up two instances of the atom driver,
as I once did with the Alpha for experiment. Although I have not tested
it, the configuration would likely work as you intend; however, both PPS
drivers would follow the same prefer peer.
There is another reason to avoid associating a PPS signal with other
than the seconds numberer. Due to small variations between the seconds
number provided by the source and second fraction provided by the PPS
and small variations between PPS signals, in can happen that the PPS
signal from one source is not in the same second as the second number
from another source. Once source could have a small positive residual
while the PPS a small negative residual. The result could be an error
very close to +-1 s. This can happen with only one PPS/source of course
(the median filter tosses the rare spike), but probably much more often
with multiple sources.
> 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"
> configuration thoughts.
> 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