[ntp:questions] Help with pps, shm and ntp and local reference clock

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Jan 7 20:25:04 UTC 2016

On 2016-01-04 12:50, Stuart Maclean wrote:
> I am working with a Legacy Linux kernel, 2.6.* with NO LinuxPPS support.
>I have not yet looked at trying to add it in.
>Our system has NO internet access.
>The system has a reference clock, call it X.
>X outputs a PPS signal and a 'seconds since the epoch' string over serial, I'll call this DATA.
>So I have XPPS and XDATA.
>My understanding is that the XDATA essentially gives an absolute timestamp to the XPPS signal.
> I want to discipline my local Linux system time to X.
>Thus far we have done this 'by hand', doing our own adjtimex calls, adjusting both the 'tick' and 'frequency' fields.
>The system is set up such that XPPS is wired to a GPIO pin and this itself produces an interrupt.
>I installed an ISR for this interrupt.
>In the ISR, first thing I do is grab system time and stuff it in a char buffer (much like the short driver in LDD3 examples and page 270 of LDD3).
>The driver then supports a char device, think /dev/ppsX, from which userspace can obtain that time.
>So what I am getting here is best estimate of local system time at time of XPPS.
> Then userspace also reads /dev/ttyXDATA to get the whole seconds XDATA associated with the XPPS.
>So now I have two timestamps, one is the reference XDATA and other is my local clock time for same moment XDATA relates to.
> I would prefer NOT to use my own local algorithms for adjtimex, but to use ntp or perhaps chrony instead.
>I have tried ntpd, using the 'shm' driver 28.
>I see from the shm_time struct that I need to populate a clockTime and a receiveTime, which I thought were exactly the two values I have above.
> I put together what I thought was a sufficient ntp.conf to describe the setup, just
> server
> It does not seem to be 'working'.
>I expected ntpd to nudge system time towards XDATA over time, compensating for its otherwise poor performance of ticking too slowly (it loses time).
>No such convergence seems to be happening, I log XDATA and localtime at XPPS and they are drifting apart, as if ntpd was a no-op.
> I then looked at gpsd.
>It seems to use not one by TWO shm areas, one for a PPS source and one for a NMEA source??
>In this model, my XDATA approximates a GPS NMEA string, i.e contains a timestamp pertaining to last PPS output.
> I don't understand why TWO time sources (refclocks??) are defined???
>Wouldn't this require FOUR timestamps in the two shm_time structs?
> I have also been reading up on all things PPS and NTP and noted that the 'ATOM driver' may be suitable??
> Perhaps I am better off as I am ??
>Perhaps ntp and/or chrony are overkill for my very localised and specialised situation?
> Any help appreciated, esp in explaining why gpsd and ntpd view a 'pps + data' reference clock as not one but TWO time sources??

linuxpps.org shows support for 2.6 - check out that page and its links.
Check out ntpd driver 20 NMEA for setting up ntpd gps directly using
symlinks /dev/gps# /dev/gpspps#, driver 22 PPS using /dev/pps#,
and ntpd driver 46 GPSD-NG if you can run a recent ntpd and gpsd.

The PPS device provides accurate seconds ticks, the message per second
(preferred)device provides only the UTC time to label each tick.

Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

More information about the questions mailing list