[ntp:questions] Re: Second Atom/PPS driver meets prefer
David L. Mills
mills at udel.edu
Mon Aug 15 16:58:12 UTC 2005
Your suggestion to trust the system clock instead of the prefer peer
would result in a timing loop. Very evil. The PPSAPI does in fact
support more than one PPS signal and that has been tested with the
Digital/HP Alpha and two atom driver instances.
So, let's assume you have two GPS receivers and two PPS signals.
Consider the case where one or more of the four sources doesn't agree
with the others. Admit them all to the selection and clustering
algoriths. What happens if the survivors include the timecode from one
receiver and the PPS signal from the other. Let's say the timecodes
differ by one second and either could in principle number the seconds.
The current model is that only one source can be the prefer peer. The
original purpose of that was to reduce the incidence of clockhopping and
the resulting jitter. It would seem possible to define others as prefer
peers just for the purpose of numbering the seconds, but I have trouble
if they disagree on which second. So, you would need at least a third
GPS receiver and let the selection algorithm decide which is true and
which is false.
Hal Murray wrote:
> The Atom/PPS driver needs to make sure the system clock is
> (well) within a second so that the time it reports isn't
> off by an integer multiple of a second. It does that by
> checking to make sure the offset of the prefered driver
> is less than clock_max.
> That seems reasonable in the normal/simple case. If you have
> a PPS signal, it's probably coming from a GPS device with
> a serial port that's connected to some other refclock driver.
> You might as well mark that as preferred.
> But what if you have 2 GPS clocks? It seems not-good to have
> to pick one as the preferred clock. You can't use the other
> PPS signal if the preferred one dies.
> Is there something obvious I'm missing? Why not check the
> system clock instead of the preferred driver?
More information about the questions