Rob wrote:
Harlan Stenn <st...@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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
