[ntp:questions] Stick to PPS, even if the prefer server fails

Harlan Stenn stenn at ntp.org
Sat Mar 28 04:06:26 UTC 2009

>>> 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.

Some PPS devices are "stand-alone" while others are "combined" with, say, a
GPS signal.

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"

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.

Harlan Stenn <stenn at ntp.org>
http://ntpforum.isc.org  - be a member!

More information about the questions mailing list