[ntp:questions] LOCL clock reachability not 377?

Rob nomail at example.com
Fri Aug 1 11:56:46 UTC 2014


Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> Rob wrote:
>> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>>> This sounds good. I think we'd have to distinguish some basic cases a
>>> few of which immediately come to my mind:
>>
>> It looks good.
>>
>> What is important for my box (but maybe only for mine...) is that there
>> is some method to feed OK/FAULT status to ntpd without a reference clock
>> driver, or with a reference clock driver that ntpd understands will not
>> provide time but only status.  That driver could be similar to SHM
>> (or it could be SHM with a fudge flag set), in that it could use a
>> shared memory segment where an external program puts a flag indicating
>> the validity of the PPS source.
>
> Even though I had mentioned your case I haven't accounted for this in 
> the examples.
>
> I think I would prefer if this could be a configuration option 
> associated with the PPS driver, so ntpd knows this PPS source only 
> provides a status but not the current absolute time.
>
> This could basically work with all types of refclock, e.g.:
>
> # refclocks with PPS signal and status, but no absolute time
> server 127.127.8.0 noselect
> server 127.127.22.0 stat 127.127.8.0  # sync state from parse driver
>
> server 127.127.28.0 noselect
> server 127.127.22.1 stat 127.127.28.0  # sync state from SHM0

Ok that looks good, but I have to check if it is possible to relay
status information through the SHM driver in a reasonable way.
(just put a valid time of zero in the clock for valid, and stop
putting time values in the clock for invalid?  is that what you
have in mind?)

>> My GPSDO is very good at providing PPS and 10 MHz, but otherwise it is
>> old and rusty.  Apparently many of them are going around in hobbyist
>> circles.  It does provide IRIG output, but that is not really useful as
>> you already indicate (and difficult to interface as well), and an RS232
>> command/status interface that only provides UTC/GPS time but no date.
>> However, on that interface there is a good indication of the search/lock
>> status and the momentary (estimated) error, which I use to generate
>> nagios alerts when it goes haywire.  For that, a daemon is running that
>> polls it every few seconds, which could be extended to write the SHM flag.
>
> In the example above the daemon could also just write the sync status to 
> the SHM segment. Since the "noselect" keyword is given ntpd would poll 
> it but not try to use it as normal refclock.

Yes but if I remember well the SHM clock does not have a sync status,
only a timestamp can be written there and a flag set that this has been done,
which will be seen by ntpd and reset again.

Well, maybe for quick results I will just pursue another path that I had
thought about in the past: in my daemon that reads the UTC time from the
GPSDO, I can combine that with the system date from the local system
clock to form a complete timestamp to put in an SHM segment.
I can then configure this in ntpd as a time source.

This will normally work okay when at least the system date is correct,
and it will be a stratum 1 time source that ntpd can lock on to when
there is no external reference.  When the system date is incorrect and
there are three external references, the situation will probably be
corrected, the system date will step, and from then on the clock is
providing correct time (within a couple of tens of ms due to the usual
serial delays).

It is like the LOCL clock, except it has an uncertainty window of a day
instead of a second.  That should solve the reboot issue.



More information about the questions mailing list