On Sep 15, 2020, at 12:47 PM, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|____ and Gravity ______|_ https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.theory.physics.ubc.ca%2F&data=02%7C01%7Crgovostes%40whoi.edu%7C054736ed4c39434c82db08d8599714d3%7Cd44c5cc6d18c46cc8abd4fdf5b6e5944%7C0%7C0%7C637357852718387997&sdata=qHAUE4iPB4YLvLVCtFetR33HnDjEowrOa%2FpWLANdNpE%3D&reserved=0
On Tue, 15 Sep 2020, Ryan Govostes wrote:
Hi all,
I am setting up chronyd on an embedded Linux device to synchronize the system clock using a GPS module. The GPS device sends NMEA strings over the character device /dev/ttyAMA1 and I have also configured /dev/pps0, both of which appear to be working OK.
The system is running Ubuntu 18.04 and the latest package versions are chronyd 3.2 and gpsd 3.17.
I configured gpsd to listen to the serial device and then added these lines to my chrony.conf:
refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2
Why those figures for ooffset? That is 1 sec offset. NMEA is not that bad.
refclock PPS /dev/pps0 refid PPS
When I run `chronyc sources` they both seem to be kind of working:
210 Number of sources = 2
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#- GPS 0 4 377 12 +128ms[ +128ms] +/- 200ms
#* PPS 0 4 377 12 +6ns[ +119ns] +/- 203ns
However it looks like the GPS source is “not combined”. Is this a degraded state, e.g., it is using one of these two sources?
Why would one want to combine GPS with PPS. PPS is good to the nanosecond
level. GPS toabut 100 ms -- that is almost a million times worse. It would be like combining your wristwatch with some clock which says "its
spring so it must be April".
Also, I am not sure why the LastRx from the PPS (or frankly either) ticks upwards so long—shouldn’t it constantly be receiving updates?
Yout tell it that POLL is 4 which means 16 seconds. So every 16 seconds that
clock is read. The driver massages the input ( once a second) to get rid of
obvious outliers but reports to chrony once every 16 seconds. Note it is a bad
idea to reduce the poll even further. Then obvious ouliers are not thrown out,
and the ability to determine the rate of the clock is degraded.
I am just using the precision / offset / delay figures that several examples use. Is there documentation on calibrating these values?
Get rid of the offset and delay. The GPS is useless except for setting actual
number of the seconds.
Finally, I read that using Unix sockets rather that shared memory is preferable, but my chronyd does not seem to create those sockets.
Why is it better? Leave things as they are. With PPS your time will be
accurate to microseconds just as things are now. Do you need any better time?
If you do need time to nanoseconds, then you will really have to throw away
your computer (its ability to read interrupts is only at the microsecond
level) and begin compensating for propagation delays in your gps unit, and
also the sawtooth offset on the ns level due to your gps receiver innards. But
then, why would you want to know the time to 1 billionth of a second?