[ntp:questions] Stick to PPS, even if the prefer server fails
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.
>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