[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 127.127.28.2
>
> 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