[ntp:questions] Stick to PPS, even if the prefer server fails
martin.burnicki at meinberg.de
Fri Apr 3 20:28:14 UTC 2009
> mills at udel.edu (David Mills) writes:
>>The intersection algorithm has been documented in several places along
>>with configuration controls to modify its behavior. Is the tyranny you
>>cite due to that algorithm or the notion of the prefer peer in the first
>>place? If the latter, do you have an alternate suggestion?
> Well, I would suggest that the atom driver has a flag-- a fudge or
> something, which would dissociate it from any prefer peer once intial lock
> had been obtained. Ie, itwould regard the PPS as the best time source
> whether any prefer peer exists or not. That way , if someone wants the
> current behaviour they can have it, and if they want the PPS to take
> precedence they can have that as well. IF you are going to have a single
> PPS driver, which you appear to want, then it is a good idea to make it
> very flexible and able to be set up to the user's desires.
If the PPS input is assigned to a refclock then the current behaviour is to
mark the associated refclock as "prefer". Unfortunately you can only mark
only other other time source as "prefer", and if you'd mark
several "prefer" sources that would be at least ambiguous.
Maybe a good way to solve this would be to do it the other way round.
Configure an atom driver and assign the pseudo IP of a refclock to it, e.g.
using a fudge command or a keyword on the configuration line. This could
tell the NTP kernel this PPS source is associated to that refclock, and it
could evaluate the refclock sync status to determine whether the PPS source
is freewheeling because the refclock fell out of sync, or not.
This would also provide a simple way to configure several PPS sources in
parallel, each associated to the configured refclock.
And, if no refclock association is defined for a PPS source, ntpd could
assume this is from an independent PPS source like a cesium.
More information about the questions