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

Unruh unruh-spam at physics.ubc.ca
Sun Mar 29 18:25:47 UTC 2009

mills at udel.edu (David Mills) writes:


>That's not the point. No matter how much you trust the Cs, do you trust 
>the seconds numbering? Say you reliably number the seconds and then 
>disconnect the numbering source. Obviously, you have to reestablish 
>nunmbering every time you reboot. Would you require renumbering when the 
>daemon is restarted? Do you assume nothing happens that might torque the 
>clock to another second, such as a stuck interrupt, or any hardware 
>disruption. How long are you willing to wait before requiring 
>renumbering? A day, a week, forever?

Clearly reboot requires a renumbering. Other than that, 
let him decide. Ie, have a flag together telling the atom driver to trust
the PPS (with the local clock's numbering of the seconds) with the number of seconds a free
running PPS will be trusted for. 
Eg, no fudge1, do not trust it without a peer to number the seconds, fudge1 0 trust it forever, fudge1 86400
trust it for a day, etc.
In all cases do not trust it until the system clock has been brought within .25
sec, say, by another clock. 

>There is a really simple thing to do exactly as you wish. Use the 
>configuration I recommended and enable orphan mode. This works only if 
>the kernel PPS is operating.

> Dave

>alkopedia at googlemail.com wrote:

>>On Mar 29, 5:12 am, mi... at udel.edu (David Mills) wrote:
>>>The intended design to detect and suppress bad reference/PPS clocks is
>>>at least two additional sources, that do not have to be reference
>>>clocks. If the reference/PPS clock sails to the sunset, the selection
>>>algorithm will vote it off and the PPS will follow.
>>In my case I would trust my PPS signal much more than any other
>>source. Why should I run a caesium frequency normal and not trust it?
>>questions mailing list
>>questions at lists.ntp.org

More information about the questions mailing list