Rob wrote:
Martin Burnicki <[email protected]> wrote:
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
Nice. Maybe a separate bug could be opened (if there isn't already one)
suggesting the use of such a better SHM interface as a mechanism to
separate the other drivers from ntpd.
I don't think there is a need to remove other existing drivers from
ntpd. If you don't want or don't need the built-in drivers you just
don't have to use them, and you can even compile ntpd without them, and
use the SHM interface exclusively.
There are other drivers beside the ones handling NMEA sentences from a
variety of GPS receivers, which work perfectly for their applications.
If you use a built-in driver then the advantage is that ntpd can just
get the time from the refclock. There's no need for another daemon or
service to be running in parallel to provide ntpd's SHM interface with
timestamps from the refclock.
On the other hand you can use SHM if it's more appropriate for your
application.
As I've already tried to make clear I'd also appreciate if there was an
additional SHM interface which is more versatile than the existing one
and maybe is easier to be used, e.g with regard to PPS timestamps.
I think it would be good for your company as well. It allows you to
develop and release a full-featured driver for your current and future
products to allow their use with ntpd without having to argue about
the addition of new drivers to a package the maintainer feels is already
too large.
We already have this, and it works very well as-is, except for the +/- 4
hour interval requirement, for which there is a workaround.
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.
That kind of hardcoded limits does not belong in either a driver or in
ntpd. If there is any such limit it should be in the .conf file.
Agreed. You could use a mode or fudge keyword to handle this.
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.
It appears you would benefit a lot from an improved SHM interface.
I also think it should present the ntpd user with an interface that
is comparable to an included driver. A driver interfaced via SHM should
not be second-class in any way and no more complicated to configure.
Agreed.
Once this has been achieved by development of a new SHM driver, there
is no reason to keep the 40 other drivers in ntpd except maybe for some
very basic ones (like the old SHM and LOCAL).
On the above sentence I don't agree, as mentioned earlier.
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". ;-)
I agree with all that, but I think it is better to do the communication
between the timing source and ntpd with only information that the timing
source has available (in the case of a PPS driver: the offset between
the PPS pulses and the nearest second tick in the system), and not be
forced to add information that the source cannot provide.
ntpd is in a better position to evaluate the provided offset from the
PPS and the absolute time in other sources (like the serial datastream
but also the information from network servers) and find the best
calculated offset.
Now gpsd has to do that with limited information and risk of mistakes.
(gpsd does not get information about other sources from ntpd, but only
looks at the serial datastream and the system clock)
Hm. There must be some place on either side of the SHM segment where the
PPS timestamp is related to the reference time.
So this could be done by ntpd or by the program that feeds the SHM
segment. In simple cases it is more straightforward to do this in ntpd,
since there's only a single routine required.
On the other hand, if a program like gpsd tries to take care of
peculiarities of different types of GPS receivers it might be better to
let gpsd handled this and just forward "normalized" time stamps to ntpd.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
