[ntp:questions] Start of new GPS 1024 week epoch
martin.burnicki at meinberg.de
Mon Aug 26 14:11:36 UTC 2013
> Martin Burnicki <martin.burnicki at meinberg.de> 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:
> 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
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.
> 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.
More information about the questions