[ntp:questions] Stick to PPS, even if the prefer server fails
unruh at physics.ubc.ca
Sat Mar 28 06:52:21 UTC 2009
Harlan Stenn <stenn at ntp.org> writes:
>>>> In article <968zl.19988$PH1.19347 at edtnps82>, Unruh <unruh-spam at physics.ubc.ca> writes:
>Unruh> That may be the logic, but it is seriously flawed. It also indicates
>Unruh> that the decision to interpret PPS separately from the other drivers
>Unruh> is flawed. atom should ONLY be used for a single separate PPS source
>Unruh> decoupled from anything else. If you rPPS is combined with nmea then
>Unruh> that nmea driver should be running the PPS since it is the
>Unruh> combination that gives the time, and it is the combination that knows
>Unruh> whether the PPS is good or not.
>Unruh> Using some heuristic like "is a prefer source available" is a pretty
>Unruh> poor substitute for knowing whether the PPS is good or not.
>I think I probably agree with you Bill.
>From one POV, it seems to me that each "instance" of a PPS source should
>come with "health information" about that PPS instance. This "health"
>information should include the current expected precision of the PPS signal.
Not sure what the health info would be. The health of PPS is either great,
(if the seconds is good) or attrocious (if the second is bad), and the
driver presumably does not know this or it would have corrected the seconds
(remember that this is like the date being a month out, if your accuracy
was a second).
>Some PPS devices are "stand-alone" while others are "combined" with, say, a
>For the former case, it makes sense to treat them as separate sources of
>For the latter, it makes sense to treat the PPS signal as an "adjunct"
Well, I would say that the GPS is the adjunct device since the PPS is far
far more accurate (4 orders of magnitude).
>See http://support.ntp.org/bin/view/Dev/GettingNtpdItsConfiguration for more
>The bottom line is we need to figure out what else needs to be done to make
>the "state of affairs" with PPS sources even more generally useful.
Clearly the PPS needs something auxilliary to determine the seconds. On the
other hand, once that second lock is obtained it is hard to lose it. The system clock
on most computers is not going to drift by 500,000 PPM
(especially not most time servers).
Now maybe I am not imaginative enough to think of what could go wrong.
More information about the questions