[ntp:questions] Start of new GPS 1024 week epoch

Rob nomail at example.com
Tue Aug 20 11:08:59 UTC 2013


Harlan Stenn <stenn at ntp.org> wrote:
> Martin Burnicki writes:
>> Rob wrote:
>> > Only the shared memory interface currently has functionality like this,
>> > and it has some limitations in the information it can convey.  If this
>> > interface is improved, all the local clock drivers can be moved out
>> > into separate processes and everyone can tinker his driver to fix problems
>> > like this one.  It will also be easier to release a fixed driver once
>> > a problem like this suddenly appears.
>> 
>> Once upon a time there was a good proposal for a new SHM interface with 
>> improved features. However, this was not accepted, and the discussion 
>> simply faded out. See:
>> http://lists.ntp.org/pipermail/questions/2011-March/028913.html
>
> The SHM refclock now supports nanoseconds, as I recall.

How was that implemented in a backward-compatible way?

> And I'd be happy to look at these issues for ntp4-5.0 too.  How about a
> bug report that refers to a topic in the Dev web for discussion?

I think the SHM refclock should support all the features available to
any other refclock, including setting a refid by the client driver, and
all the features mentioned in the mailing list article Martin referenced.

It should be that good that there no reason whatsoever to link drivers
to ntpd.  When that is finished, all drivers except the new shm refclock
driver should be removed from ntpd, and repackaged as standalone programs
interfacing to ntpd via SHM.

If wanted, ntpd could be extended to allow the startup of a driver via
a server specification in ntp.conf, to allow for a smooth migration and to
support operating systems where installation and starting of all those
drivers is not so straightforward.

When all that is finished, drivers for specific hardware are no longer
an issue that Dave has to be involved in.



More information about the questions mailing list