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

Martin Burnicki martin.burnicki at meinberg.de
Tue Aug 20 12:25:39 UTC 2013


Rob wrote:
> 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?

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 
system time.

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 
gpsd. See:

Bug 1232 - nanosecond support in SHM driver
https://bugs.ntp.org/show_bug.cgi?id=1232

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list