[ntp:hackers] LinuxPPS + 2.6 kernel + ntpd?

Armen Babikyan armenb at ll.mit.edu
Thu Jan 5 21:54:48 UTC 2006


Hi,

I have a Garmin GPS 25LP that I have connected to a serial port on my 
linux 2.6 laptop, and I need to get my system's clock synchronized with 
the PPS signal from the GPS.  I've verified that my GPS is indeed 
outputting the PPS signal (100ms-long pulse, once a second) with an 
oscilloscope and gpsd (which will output messages relating to getting or 
losing carrier detect on the serial line).

At this point, I've patched both my kernel (vanilla 2.6.13) and ntp-dev 
(from less than a week ago) with Rodolfo Giometti's LinuxPPS patches:

http://www.enneenne.com/index.php?appl=menu&request=Projects&name=linuxpps

(For those who don't know, and as far as I can tell, LinuxPPS grew out 
of Ulrich Windl's PPSkit, and looks to be a PPSkit-equivalent that 
provides netlink sockets rather than ioctl()s to communicate with the 
kernel.  It has *almost* the same API as PPSkit, with some minor 
modifications.  These mods were described by Rodolfo recently in the 
ntp:questions mailing list).  For me, the last PPSkit patch has been for 
Linux 2.6.5 kernel, which I've unsuccessfully "ported" (i.e. just 
hand-integrated the code that 'patch' rejected) - I get kernel panics.  
In comparison, LinuxPPS has patches for the 2.6.13 kernel, I don't get 
kernel panics, and I seem to be having more luck with this patch.  
However, I'm still having trouble getting ntpd to synchronize with the 
PPS signal.

Just so I understand, I am under the impression that refclock_nmea.c has 
some mention of PPS in it because it knows how to give an accurate clock 
reading with NMEA timestamps combined with PPS.  Does this sound right?  
In other words, I do not need a separate refclock_atom 127.127.22.0 
driver, correct?  Assuming this is true...

Right now, this is the typical output I get from ntpq -p:

    remote           refid      st t when poll reach   delay   offset  
jitter
============================================================================== 

*GPS_NMEA(0)     .GPS.            0 l   29   64  377    0.000  -223.92 
124.278

That -223.92ms offset seems relatively low right now.  I've seen it as 
high as -700ms (when compared with a local network time server).  This 
sounds like ntp is only synchronizing with the slow 4800bps NMEA 
message, and not the PPS pulse.  When I fire up ntpd, I get these 
messages in startup to indicate that it is was able to initialize pps 
stuff to some degree:

addto_syslog: refclock_nmea: found PPS source #0 "pps_8250_0" on ""
refclock_ppsapi: capability 0x1111 version 1 mode 0x1101 kern 0
newpeer: 127.0.0.1->127.127.20.0 mode 3 vers 4 poll 6 10 flags 0x10a1 
0x1 ttl 2 key 00000000
getaddrinfo 127.127.20.0
getnetnum given 127.127.20.0, got 127.127.20.0
refclock_ppsapi: capability 0x1111 version 1 mode 0x1101 kern 0
addto_syslog: frequency initialized 14.174 PPM from /var/lib/ntp/drift
authtrust: keyid 0000ffff life 1
local_clock: time 0 base 0.000000 offset 0.000000 freq 14.174 state 1
report_event: system event 'event_restart' (0x01) status 'sync_alarm, 
sync_unspec, 1 event, event_unspec' (0xc010)

Here is the contents of my /etc/ntp.conf:

server 127.127.20.0
fudge  127.127.20.0 flag2 0 flag3 0
driftfile /var/lib/ntp/drift

flag2 is 0 because my kernel says it doesn't have the PPS_CAPTURECLEAR 
capability (not sure if this is true or not - I am certainly seeing two 
messages a second with debugging turned on in my /var/log/messages).  
flag3 is 0 because the PPS patches for 2.6 don't have hardpps support.

I have experimented with using the refclock_atom PPS driver while using 
the refclock_nmea driver, but there is serial port contention there, so 
that doesn't work.  I tried synchronizing refclock_atom with the local 
clock (127.127.1.0) and a known good local timeserver, but no luck there 
either:

    remote           refid      st t when poll reach   delay   offset  
jitter
============================================================================== 

PPS(0)          .PPS.            0 l    -   64    0    0.000    0.000   
0.004
*timebox         .GPS.            1 u   63   64  377    5.066    0.603   
0.618

Incidently, my metric for success is that I will have a time source 
(PPS, or GPS_NMEA) in 'ntpq -p' that records very low jitter and very 
low offset, and the little * by the name.  Is this a valid expectation 
of a working PPS/ntp synchronization setup?  In any case, my application 
requires me to get PPS working with GPS NMEA messages, as there won't be 
a network time server available.

Are there any other things I should try?  I'm not sure what to try that 
I haven't tried already.  Believe me, I will definitely be creating a 
tutorial/howto if and when this finally works right!

Any and all help/advice is greatly appreciated. :)

 - Armen

-- 
Armen Babikyan
MIT Lincoln Laboratory
armenb at ll.mit.edu . 781-981-1796 



More information about the hackers mailing list