[ntp:questions] LOCL clock reachability not 377?

Martin Burnicki martin.burnicki at meinberg.de
Thu Jul 31 08:43:20 UTC 2014


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.

On the other hand, if a PPS input signal is associated to a particular 
time source the PPS signal could be discarded if the associated time 
source becomes unreachable.

> Also, you may have (I do have) a GPSDO that provides PPS and status info,
> but no time.  So I know when the PPS is valid, but I don't have an NMEA
> or TSIP or whatever stream to feed to a reference clock driver.

I'm sure there would also be a way to configure such specific setup.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list