[LinuxPPS] Recommendation / Re: Stats & architectures

[Robert Jenkins]

From: Remco den Besten 11 March 2008 17:02

> Subject: [LinuxPPS] Recommendation / Re: Stats & architectures
> 
> In order to reduce uncertainties whether Rodolfo's PPS API 
> works, I STRONGLY 
> recommend
> the following:
> 
> Use the ATOM (driver22) for PPS --in _conjunction with 
> another driver_ which 
> is
> able to handle Rodolfo's PPS-API/kernel patch-- (i.e. Motorola Oncore 
> (driver31) or
> NMEA (driver20 with the patch from Udo) with ntpd-4.2.4p2).
> 
> Of course, prior to all doing this: follow the LinuxPPS-wiki.
> 
> Do NOT activate the PPS option for the ONCORE or NMEA driver 
> (flag3 = 0), 
> i.e. in ntp.conf :
> #NMEA 4800 bps on ttyS1 no PPS enabled, low stratum because 
> NMEA is used as 
> 'enabler'/dummy
> server 127.127.20.1 prefer # <- necessary for the ATOM driver 
> to lock on
> fudge 127.127.20.1 time1 0.0 stratum 15 flag2 1 flag3 0 refid NMEA
> 
> but activate the ATOM driver instead:
> #ATOM PPS on ttyS1 (falling edge flag2 1)
> server 127.127.22.1
> fudge 127.127.22.1 time1 0.0 flag2 1 flag3 1 stratum 0 refid PPS
> 
> Restart ntpd and after a while ntpd is locked onto the NMEA 
> driver (mostly
> after 4 cycles, i.e. with a reach of '17' (<- octal 1111) 
> GPS_NMEA(1) gets a 
> '*')
> When the NMEA time is within (I thought) 500 ms of the 'real' 
> time, the ATOM
> driver will take over and a 'o' (i.e. oPPS(1) in this 
> example) is visible 
> when querying with 'ntpq -p'.
> After that the PLL will converge to its value. You will 
> always experience 
> jitter and deviations,
> depending upon the load of the system and/or temperature 
> variations, etc. 
> This a whole science
> in itself (aka timekeeping ;-)
> 
> When you see no 'o', the PLL does not have a PPS lock. <- period ;-)
> 
> With no PPS lock you can not say anything about the quality, precision
> or stability of the system / PPS-API.
> 
> First get an 'o', then worry later ;-)
> 


Hi Remco,
many thanks for that info.

I've rebuilt ntp to include the Atom refclock and enabled that in ntp.conf.
I also disabled PPS for the NMEA refclock.

This is the first time I've ever started ntpd without it jumping or hunting,
even when it's previously been in lock and had a valid drift file.
It's immediately showing an offset of just 0.003 and jitter 0.001

In lock within a couple of minutes 'oPPS(0)' and so far looking dead stable!

It does possibly show up a bug in the NMEA refclock? With 'flag3 0' it seems
to still be trying to use PPS -

Mar 11 18:53:39 gate ntpd[28986]: kernel time sync status 0040
Mar 11 18:53:39 gate ntpd[28986]: refclock_atom: time_pps_kcbind failed:
Operation not supported
Mar 11 18:53:39 gate ntpd[28986]: refclock_nmea: found GPS source
"/dev/gps0"
Mar 11 18:53:39 gate ntpd[28986]: refclock_nmea: try alternate PPS device
"/dev/pps0"
Mar 11 18:53:39 gate ntpd[28986]: refclock_nmea: found PPS source
"/dev/pps0"			<<<<<<<
Mar 11 18:53:39 gate ntpd[28986]: frequency initialized -66.028 PPM from
/var/lib/ntp/drift
Mar 11 18:54:30 gate ntpd[28986]: synchronized to GPS_NMEA(0), stratum 9
Mar 11 18:54:30 gate ntpd[28986]: kernel time sync status change 0001
Mar 11 18:55:21 gate ntpd[28986]: synchronized to PPS(0), stratum 0

Overall this looks much, much better - the error and jitter are (so far)
staying low and the poll interval to other machines is ramping up - it was
rarely above the minimums previously, presumably due to the poor jitter
values.


Thanks again,
Robert.