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

Stuart Maclean stuart at apl.washington.edu
Mon Jan 4 19:50:37 UTC 2016


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

Stuart



More information about the questions mailing list