Rob wrote:
> 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.
I absolutely agree, and, as requested by Harlan, I've just opened a
bugzilla issue for this, so this can be tracked more easily:
http://bugs.ntp.org/2470
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
from eachother.
ntps apparently supports PPS clocks when they are compiled with the
program, but not via SHM.
As usual it depends.
As far as I know the reference time provided via the SHM driver needs to
be within +/-4 hours of the current system time.
For example, we (Meinberg) use the SHM driver to provide ntpd with the
time from our PCI cards, plus the system time associated to the
reference time stamp.
Those cards know the absolute date and time and thus could correct the
PC's system time if that time was significantly off. However, the +/- 4
hours limitation prevents from doing this easily, so you have to provide
a workaround which sets the system time roughly to be inside this
interval, and then start submitting timestamps via SHM.
This is basically similar to the outdated approach where you had to run
ntpdate first to set the system time roughly, and then start ntpd to do
the fine adjustment.
Of course things are different if you get the reference timestamps from
a 1 PPS signal. These timestamps usually have been taken from the system
time when the PPS slope was detected, so there must be in any case a
different approach to relate this to the absolute reference time, which
may be from the same hardware refclock, or from some other time source.
You can either let ntpd and/or the kernel handle this, e.g. via the ATOM
driver and/or kernel PPS, or you could let some other driver deal with
this, compute an absolute timestamp from the PPS time plus inaccurate
reference time, and pass only the corrected reference timestamps to ntpd.
So in any case there needs to be some code which relates the PPS time
stamps to the refclock time, and this can be inside ntpd or the kernel,
or in one of ntpd's refclock drivers (e.g. the parse driver, driver 8,
can do this), or inside an external "driver", i.e. some other daemon
feeding corrected timestamps to the SHM segment.
If there is a requirement for extreme situations, e.g. that there is a
large offset between the time from a serial string and an associated PPS
slope, this may require some change in the existing code to cope with this.
So of course you could add some flag, mode or whatever to a SHM driver
to tell ntpd the reference time stamp passed to SHM is a "PPS time"
instead of an absolute time, and ntpd could do the conversion.
However, this just means ntpd rather than gpsd had to care about what
you call "mixing". ;-)
So a criterion may be at which of the points mentioned above the
necessary patch is accepted, picked up, and rolled out in the shortest
time frame. ;-)
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
