[ntp:questions] Start of new GPS 1024 week epoch

Rob nomail at example.com
Fri Aug 23 17:46:32 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:
> 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 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.

>> 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.

> 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).

> 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)

I think that it is best to let every timing source provide what it can,
be it absolute time or relative time offsets, via different modes of
the new SHM interface, and then let ntpd (and/or the kernel) use the
information at best value.

gpsd was written when PPS support in the Linux kernel was a separate
patch that was not in generally distributed kernels, so it does not
rely on any kernel support.  It used a usermode thread that waits for a
transition on a serial interface line and then timestamps this transition.
Today it can also use the PPS support that has been included in Linux.
But in other systems, the old method may still be the only one available.

More information about the questions mailing list