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

Unruh unruh-spam at physics.ubc.ca
Fri Mar 27 17:33:57 UTC 2009


David Woolley <david at ex.djwhome.demon.co.uk.invalid> writes:

>Unruh wrote:

>> 
>> I have now looked at the refclock_atom source and indeed, it demands that a
>> prefer clocksource is available, and ignores the PPS if it is not. This I
>> believe is a bug, or at least a design infelicity. You could either hack

>I suspect the reasoning may be that both normally come from the same 
>radio clock which will free-run the PPS when it loses a signal, so that 
>detecting the failure of the NMEA data is the only way of telling that 
>the PPS data is unreliable.

That may be the logic, but it is seriously flawed. It also indicates that
the decision to interpret PPS separately from the other drivers is flawed.
atom should ONLY be used for a single separate PPS source decoupled from
anything else. If you rPPS is combined with nmea then that nmea driver
should be running the PPS since it is the combination that gives the time,
and it is the combination that knows whether the PPS is good or not. 

Using some heuristic like "is a prefer source available" is a pretty poor
substitute for knowing whether the PPS is good or not. 




More information about the questions mailing list