Chrony supports various PPS types natively. It can use kernel PPS API as well as PTP hardware clock.
Most general GPS receivers can be leveraged via GPSD. The latter (and potentially more) can be accessed viaSHM or via a socket(recommended). All of the above can be used to augment chrony with additional high quality time sources for better accuracy, jitter, drift, longer-or-short term accuracy (Usually each kind of clock type is good at one of those, but non-perfect at the others). For more details on configuration see some of the external PPS/GPSD resource listed below.
Note: at the release of 20.04 there was a bug which until fixed you might want to add this content to your /etc/apparmor.d/local/usr.sbin.gpsd.
Example configuration for GPSD to feed Chrony
For the setup you need $ sudo apt install gpsd chrony
But you will want to test/debug your setup and especially the GPS reception, therefore also install $ sudo apt install pps−tools gpsd−clients
GPS devices usually will communicate via serial interfaces, yet the most common type these days are USB GPS devices which have a serial converter behind USB. If you want to use this for PPS please be aware that the majority does not signal PPS via USB. Check the GPSD hardware list for details. The examples below were run with a Navisys GR701-W.
When plugging in such a device (or at boot time) dmesg should report serial connection of some sorts, example:
[ 5 2 . 4 4 2 1 9 9 ] usb 1−1.1: new f u l l−s p e e d USB d e v i c e number 3 u s i n g xhci_hcd [ 5 2 . 5 4 6 6 3 9 ] usb 1−1.1: New USB d e v i c e found , idVendor =067b , i d P r o d u c t =2303 ,
bcdDevice= 4 . 0 0
[ 5 2 . 5 4 6 6 5 4 ] usb 1−1.1: New USB d e v i c e s t r i n g s : Mfr=1, Product =2, SerialNumber=0
[ 5 2 . 5 4 6 6 6 5 ] usb 1−1.1: Product : USB−S e r i a l C o n t r o l l e r D [ 5 2 . 5 4 6 6 7 5 ] usb 1−1.1: Manufacturer : P r o l i f i c Technology I n c .
[ 5 2 . 6 0 2 1 0 3 ] u s b c o r e : r e g i s t e r e d new i n t e r f a c e d r i v e r u s b s e r i a l _ g e n e r i c [ 5 2 . 6 0 2 2 4 4 ] u s b s e r i a l : USB S e r i a l s u p p o r t r e g i s t e r e d f o r g e n e r i c
[ 5 2 . 6 0 9 4 7 1 ] u s b c o r e : r e g i s t e r e d new i n t e r f a c e d r i v e r p l 2 3 0 3 [ 5 2 . 6 0 9 5 0 3 ] u s b s e r i a l : USB S e r i a l s u p p o r t r e g i s t e r e d f o r p l 2 3 0 3 [ 5 2 . 6 0 9 5 6 4 ] p l 2 3 0 3 1−1 . 1 : 1 . 0 : p l 2 3 0 3 c o n v e r t e r d e t e c t e d
[ 5 2 . 6 1 8 3 6 6 ] usb 1−1.1: p l 2 3 0 3 c o n v e r t e r now a t t a c h e d t o ttyUSB0
We see above that it appeared as ttyUSB0. To later on have chrony accept being feeded time information by that we have to set it up in /etc/chrony/chrony.conf (Please replace USB0 to whatever applies to your setup):
r e f c l o c k SHM 0 r e f i d GPS p r e c i s i o n 1 e−1 o f f s e t 0 . 9 9 9 9 d e l a y 0 . 2 r e f c l o c k SOCK / var / run / chrony . ttyUSB0 . s o c k r e f i d PPS
Then restart chrony to make the socket available and waiting. sudo systemctl restart chrony
Next one needs to tell gpsd which device to manager, therefore in /etc/default/gpsd we set: DEVICES=”/
dev/ttyUSB0”
Furthermore the default use-case of gpsd is, well for gps position tracking. Therefore it will normally not consume any cpu since it is not running the service but waiting on asocketfor clients. Furthermore the client will then tell gpsd what it requests and gpsd will only do that. For the use case of gpsd as PPS-providing-daemon you want to set the option to:
• immediately start even without a client connected, this can be set in GPSD_OPTIONS of /etc/default /gpsd:
– GPSD_OPTIONS=”−n”
• enable the service itself and not wait for a client to reach the socket in the future:
– sudo systemctl enable /lib/systemd/system/gpsd.service
Restarting gpsd will now initialize the PPS from GPS and in dmesg you will see p p s _ l d i s c : PPS l i n e d i s c i p l i n e r e g i s t e r e d
pps pps0 : new PPS s o u r c e u s b s e r i a l 0 pps pps0 : s o u r c e ”/ dev /ttyUSB0 ” added
In case you have multiple PPS the tool ppsfind might be useful to identify which PPS belongs to which GPS.
You could check that with:
$ sudo p p s f i n d / dev /ttyUSB0
pps0 : name=u s b s e r i a l 0 path=/dev /ttyUSB0
To get any further you need your GPS to get a lock. Tools like cgps or gpsmon need to report a 3D Fix for the data being any good. Then you’d want to check to really have PPS data reported on that with ppstest
$ c g p s . . . �
S t a t u s : 3D FIX ( 7 s e c s ) . . .
Next one might want to ensure that the pps device really submits PPS data, to do so run ppstest:
$ sudo p p s t e s t / dev / pps0 t r y i n g PPS s o u r c e ”/ dev / pps0 ” found PPS s o u r c e ”/ dev / pps0 ”
ok , found 1 s o u r c e ( s ) , now s t a r t f e t c h i n g data . . .
s o u r c e 0 − a s s e r t 1 5 8 8 1 4 0 7 3 9 . 0 9 9 5 2 6 2 4 6 , s e q u e n c e : 69 − c l e a r 1 5 8 8 1 4 0 7 3 9 . 9 9 9 6 6 3 7 2 1 , s e q u e n c e : 70
s o u r c e 0 − a s s e r t 1 5 8 8 1 4 0 7 4 0 . 0 9 9 6 6 1 4 8 5 , s e q u e n c e : 70 − c l e a r 1 5 8 8 1 4 0 7 3 9 . 9 9 9 6 6 3 7 2 1 , s e q u e n c e : 70
s o u r c e 0 − a s s e r t 1 5 8 8 1 4 0 7 4 0 . 0 9 9 6 6 1 4 8 5 , s e q u e n c e : 70 − c l e a r 1 5 8 8 1 4 0 7 4 0 . 9 9 9 7 8 6 6 6 4 , s e q u e n c e : 71
s o u r c e 0 − a s s e r t 1 5 8 8 1 4 0 7 4 1 . 0 9 9 7 9 2 4 4 7 , s e q u e n c e : 71 − c l e a r 1 5 8 8 1 4 0 7 4 0 . 9 9 9 7 8 6 6 6 4 , s e q u e n c e : 71
Ok, gpsd is now running, the GPS reception has found a fix and this is fed into chrony. Now lets check that from the point of view of chrony.
Initially (e.g. before gpsd has started or before it has a lock) those will be new and “untrusted” sources marked with an “?”. If your devices stay in the “?” state and won’t leave it even after quite some time then gpsd seems not to feed any data to chrony and you’d need to debug why.
chronyc> s o u r c e s
210 Number o f s o u r c e s = 10
MS Name/ IP a d d r e s s Stratum P o l l Reach LastRx Last sample
===============================================================================
#? GPS 0 4 0 − +0ns [ +0ns ] +/− 0
ns
#? PPS 0 4 0 − +0ns [ +0ns ] +/− 0
ns
Over time chrony will classify them as good or bad. In the example case the raw GPS had too much deviation but PPS is good.
chronyc> s o u r c e s
210 Number o f s o u r c e s = 10
MS Name/ IP a d d r e s s Stratum P o l l Reach LastRx Last sample
===============================================================================
#x GPS 0 4 177 24 −876ms [ −876ms ] +/− 200ms
#− PPS 0 4 177 21 +916 us [ +916 us ] +/− 63 us
^− c h i l i p e p p e r . c a n o n i c a l . com 2 6 37 53 +33us [ +33us ] +/− 33ms And finally after a while it used the hardware PPS input as it was better:
chronyc> s o u r c e s
210 Number o f s o u r c e s = 10
MS Name/ IP a d d r e s s Stratum P o l l Reach LastRx Last sample
===============================================================================
#x GPS 0 4 377 20 −884ms [ −884ms ] +/− 200
ms
#* PPS 0 4 377 18 +6677 ns [ +52us ] +/− 58
us
^− alphyn . c a n o n i c a l . com 2 6 377 20 −1303 us [−1258 us ] +/− 114 ms
The PPS might also be ok but used in a combined way with e.g. the selected server. See man chronyc for more details about how all these combinations will look like.
chronyc> s o u r c e s
210 Number o f s o u r c e s = 11
MS Name/ IP a d d r e s s Stratum P o l l Reach LastRx Last sample
===============================================================================
#? GPS 0 4 0 − +0ns [ +0ns ] +/− 0
ns
#+ PPS 0 4 377 22 +154 us [ +154 us ] +/− 8561
us
^* c h i l i p e p p e r . c a n o n i c a l . com 2 6 377 50 −353 us [ −300 us ] +/− 44 ms
And if you wonder if your shm based GPS data is any good, you can check for that as well. First of all chrony will not only tell you if it classified it as good or bad. Via sourcestats you can also check the details chronyc> s o u r c e s t a t s
210 Number o f s o u r c e s = 10
Name/ IP Address NP NR Span Frequency Freq Skew O f f s e t Std Dev
==============================================================================
GPS 20 9 302 +1.993 1 1 . 5 0 1 −868ms 1208 us
PPS 6 3 78 +0.324 5 . 0 0 9 +3365 ns 41 us
golem . c a n o n i c a l . com 15 10 783 +0.859 0 . 5 0 9 −750 us 108 us You can also track the raw data that gpsd or other ntpd compliant refclocks are sending via shared memory by using ntpshmmon:
$ sudo ntpshmmon −o ntpshmmon : v e r s i o n 3 . 2 0
# Name O f f s e t Clock Real L
Prc
sample NTP1 0 . 0 0 0 2 2 3 8 5 4 1 5 8 8 2 6 5 8 0 5 . 0 0 0 2 2 3 8 5 4 1 5 8 8 2 6 5 8 0 5 . 0 0 0 0 0 0 0 0 0 0
−10
sample NTP0 0 . 1 2 5 6 9 1 7 8 3 1 5 8 8 2 6 5 8 0 5 . 1 2 5 9 9 9 8 5 1 1 5 8 8 2 6 5 8 0 5 . 0 0 0 3 0 8 0 6 8 0
−20
sample NTP1 0 . 0 0 0 3 4 9 3 4 1 1 5 8 8 2 6 5 8 0 6 . 0 0 0 3 4 9 3 4 1 1 5 8 8 2 6 5 8 0 6 . 0 0 0 0 0 0 0 0 0 0
−10
sample NTP0 0 . 1 3 0 3 2 6 6 3 6 1 5 8 8 2 6 5 8 0 6 . 1 3 0 6 3 4 9 4 5 1 5 8 8 2 6 5 8 0 6 . 0 0 0 3 0 8 3 0 9 0
−20
sample NTP1 0 . 0 0 0 4 8 5 2 1 6 1 5 8 8 2 6 5 8 0 7 . 0 0 0 4 8 5 2 1 6 1 5 8 8 2 6 5 8 0 7 . 0 0 0 0 0 0 0 0 0 0
−10
References
• Chrony FAQ
• ntp.org: home of the Network Time Protocol project
• pool.ntp.org: project of virtual cluster of timeservers
• Freedesktop.org info on timedatectl
• Freedesktop.org info on systemd-timesyncd service
• Feeding chrony from GPSD
• See the Ubuntu Time wiki page for more information.