[ntp:questions] Start of new GPS 1024 week epoch
nomail at example.com
Tue Aug 20 13:51:27 UTC 2013
Martin Burnicki <martin.burnicki at meinberg.de> wrote:
> 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:
>>> 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
Aha, ok... that is a solution, but I think it is a good idea to draw
a new SHM specification that adds a lot of functionality like described
in the mailing list article, and make it the prime reference clock interface
for ntpd. ntpd can then focus on the main task: the network support and
the sacred loop, while those pesky drivers can be kept separate.
There is another featurure missing from SHM: a reference clock can only
supply absolute time. There should be a mode where the clock only
provides difference information.
That would be used by the PPS thread in gpsd. It now has to borrow the
absolute time info from the serial interface, and add the PPS information
to it. That causes trouble, because the serial interface sometimes has
a large offset. It would be better when this mixing was not required and
the serial interface and the PPS interface can operate completely independent
ntps apparently supports PPS clocks when they are compiled with the
program, but not via SHM.
More information about the questions