> Finally, I read that using Unix sockets rather that shared memory is
preferable, but my chronyd does not seem to create those sockets.

You need to check the AppArmor policies in-use. Broken gpsd ones were
shipped to Ubuntu users, make sure gpsd has access to the chrony sockets
and the pps device. If it doesn't it'll fail with a nondescript error or
silently. Super annoying piece of software. PPS0 is also hardcoded in gpsd,
the passed devices don't matter.

Then you need to make sure they're started in the right order for the
socket method to work, chrony before gpsd if I remember correctly. Another
point of pointless fragility in gpsd. SHMs work a bit better and then the
order doesn't matter, again, check the AppArmor policy if they both can
access the segments.

Oh and finally, it might take a bit of time before any readings appear in
chrony. Both chrony and gpsd are annoyingly opaque about any potential
problems in such a setup.



On Tue, Sep 15, 2020 at 5:31 PM Ryan Govostes <rgovos...@whoi.edu> 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
>         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?
>
> 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?
>
> I am just using the precision / offset / delay figures that several
> examples use. Is there documentation on calibrating these values?
>
> Finally, I read that using Unix sockets rather that shared memory is
> preferable, but my chronyd does not seem to create those sockets.
>
> Thanks,
> Ryan

Reply via email to