[ntp:questions] LOCL clock reachability not 377?

Rob nomail at example.com
Thu Jul 31 08:53:54 UTC 2014


Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> Rob schrieb:
>> A C <agcarver+ntp at acarver.net> wrote:
>>> ATOM always stops when the prefer peers die even if there are other
>>> peers available but not marked prefer.  I'm still running an older
>>> development version (4.2.7p270) that I modified to remove all the prefer
>>> code so that the selection algorithm continues to run normally without
>>> shutting down the ATOM driver as peers come and go.  If all the peers
>>> die then ATOM will stop, too since there's no more selected clock.
>>
>> Yes this is where the problem is.   The ATOM clock needs to have some
>> way of determining that the PPS pulses are valid, and the kludge to use
>> the existing "prefer" keyword to indicate a clock that is to be used
>> for that is causing all the trouble.
>>
>> The designer probably believed that any clock that provides PPS would
>> also output some serial stream with less accurate time and also status,
>> and that this would then be marked prefer.  When that clock is OK, the
>> PPS is also OK.
>>
>> However, that is broken.  Not only do you probably not want to mark
>> that clock prefer (external references are often more accurate than the
>> serial NMEA time, for example), but also you may have two or more ATOM
>> PPS clocks, each with their own status, and there is no way to do that
>> with this method.
>
> I've already proposed some times ago that another way of assigning PPS 
> signal(s) to other time source(s) would be more versatile:
> http://lists.ntp.org/pipermail/questions/2009-April/022599.html
> http://lists.ntp.org/pipermail/questions/2009-April/022600.html
>
> This would also provide a simple way to declare a PPS signal "reliable", 
> e.g. if it is derived from a Rubidium or so, in which case it could 
> continue to be accepted even though other time sources become unreachable.

Yes, I see you are thinking along the same lines as I was.
There has to be some defined relation between the PPS and a refclock,
and it should not be via "prefer", but using some fudge.
And, there should be the possibility (maybe some dummy refclock) to
send status information without also providing time information.

Unfortunately it is very customary for PPS devices to always send their
pulses even when they are not locked.  This may make some sense when
lock is lost after it had been available, and the device continues to
free run with some accuracy.  However, it is also done when the device
coldstarts and the PPS makes no sense at all.
So separate status information certainly is required.  But not in the
kludgy way it is provided now.



More information about the questions mailing list