[ntp:questions] LOCL clock reachability not 377?

Rob nomail at example.com
Tue Jul 29 20:43:29 UTC 2014


A C <agcarver+ntp at acarver.net> wrote:
> On 2014-07-29 11:33, William Unruh wrote:
>> On 2014-07-29, Rob <nomail at example.com> wrote:
>
>>> The reasoning is that once the time is locked to PPS, it should remain
>>> close enough for the local clock to be trusted as an absolute time
>>> source (this system is rarely rebooted).
>> 
>> It should do that even if the external clocks disconnect. 
>> But I do not know if in your setup your system refuses to use the ATOM
>> if the external clocks disconnect-- that would be stupid, but....
>
> 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.

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.

What would be required is a parameter for the ATOM clock where one can
specify which clock to use as a valid indicator for that PPS, without
marking that clock as prefer in the same go, and with the option to
specify another indicator (e.g. an SHM segment or other IPC mechanism)
where an external program can put valid/not valid information for the
PPS pulses without the obligation to specify current time.

Then I can configure the ATOM clock with that method and use my external
monitoring program to control the PPS valid flag, without messing with
external clocks and prefer.

Of course I would still list some external servers to initially sync
the clock to within a second, and handle the leap second issue.  But
when they are lost, there should be no reason for the PPS to become
invalid at the same time.

> Modifying the code also gave me the opportunity to decouple the
> minpoll/maxpoll pinng that happens between the local refclocks and
> external servers[1] -- the suggested configurations for many refclocks
> have maxpolls that conflict to the operational etiquette for Internet
> servers plus it prevents the automatic scaling of the poll time to those
> servers.
>
>
>
> [1] ATOM's own documentation suggest maxpoll of 4 to 6 to keep the clock
> synced to PPS.  But that pins everything else to the same value unless a
> minpoll is set on the other servers.  However, once minpoll is set, the
> combination of the pinning by ATOM plus the forced required minpoll
> means the external servers never change polling period nor do they get
> the opportunity to start at the short 64s polling interval during
> initial daemon startup and then ramp to some comfortable value in the
> 1000 second range.

You are right, that is another issue I encountered.

In case you wonder how I lost all external clocks: FILTERING.
Lately, I encounter lots of NTP filtering in the internet, making
clocks that were previously reachable, suddenly unreachable.

Often this filtering occurs only for 123->123 traffic.  There really
should be an option in ntpd to specify source port for outgoing NTP
queries!  I could work around the filters by using the NAT facilities
in the Linux kernel to translate the source port to 12300.  That should
be possible inside ntpd, for clarity.



More information about the questions mailing list