First, disable systemd-timesyncd if you're using chrony: *sudo systemctl disable --now systemd-timesyncd*
Second, enable chrony, pretty sure it isn't enabled by default after install: *sudo systemctl enable chrony* Why do you want to SHM 0 (non-PPS-corrected) NMEA time, instead of SHM 1 or /var/run/chrony.ttyAMA0.sock? On Tue, Sep 15, 2020 at 9:36 PM Ryan Govostes <rgovos...@whoi.edu> wrote: > Thanks, I removed the offset and delay so the reference clock > configuration is now: > > refclock SHM 0 refid GPS precision 1e-1 > refclock PPS /dev/pps0 refid PPS > > My intention is to have GPS set the system date and time and then have the > PPS signal keep it from drifting. > > After applying this, I ran again and am now getting: > > MS Name/IP address Stratum Poll Reach LastRx Last sample > > =============================================================================== > #x GPS 0 4 377 16 +587us[ > +587us] +/- 100ms > #x PPS 0 4 160 82 -128ms[ > -128ms] +/- 759ns > > The #x suggests that “time may be in error.” However I am still seeing > gpsd work (monitored via cgps) and the PPS device still appears to be > working (according to ppstest). > > Furthermore timedatectl suggests that the system clock is not synchronized: > > $ timedatectl status > Local time: Tue 2020-09-15 18:34:48 UTC > Universal time: Tue 2020-09-15 18:34:48 UTC > RTC time: n/a > Time zone: Etc/UTC (UTC, +0000) > System clock synchronized: no > systemd-timesyncd.service active: yes > RTC in local TZ: no > > What appears to be the problem? > > Ryan > > > On Sep 15, 2020, at 12:47 PM, Bill Unruh <un...@physics.ubc.ca> 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 |____ un...@physics.ubc.ca > > 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? > >
