[ntp:questions] Start of new GPS 1024 week epoch
martin.burnicki at meinberg.de
Tue Aug 20 12:25:39 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:
>> The SHM refclock now supports nanoseconds, as I recall.
> How was that implemented in a backward-compatible way?
There were 2 fields in the SHM segment which were previously unused and
are now used to take the nanoseconds from the refclock and from the
Thus programs like gpsd can now write the nanoseconds in addition to the
microseconds. If there's an old version of ntpd running then it just
evaluates the microseconds, but new versions (ntp-dev for now) check if
the nanoseconds fields are filled up and use them if this is the case.
Thus an old ntpd works with a new gpsd, and a new ntpd works with an old
Bug 1232 - nanosecond support in SHM driver
More information about the questions