Questions about GPSD as a time source with Chrony

[Dominick C. Pastore]

Hi everyone,

I've got a few questions about setting up GPSD as a time source for Chrony.

For some background:
- I'm running on 64-bit Raspberry Pi OS, based on Debian 11 with Linux 5.15.30.
- The GPS is a u-blox MAX-M8Q over serial with PPS (one of the Uputronics 
boards).
- I'm running Chrony 4.0 from the OS repositories.
- I built GPSD from the Git master branch yesterday with these options: 
timeservice=yes magic_hat=yes nmea0183=yes ublox=yes fixed_port_speed=9600 
fixed_stop_bits=1 controlsend=yes

Question 1:

This first question is more of a troubleshooting issue. The GPSD Time Service 
HOWTO suggests using the socket interface. But the socket interfaces aren't 
behaving as expected: The NMEA socket seems to be passing PPS data, and the PPS 
socket isn't passing any useful data at all. The weird thing is, if I use the 
shared memory interface instead, both sources work as expected. Any idea why 
this could be happening with the socket interface?

For reference, here is sample output from "chronyc sources" with all four 
sources configured. Notice how GPSO has similar error to PPSH, and PPSO isn't producing 
samples at all:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#x GPSH                          0   4   377    20   +143ms[ +143ms] +/-  180us
#* PPSH                          0   4   377    21   -337ns[ -843ns] +/-  123ns
#- GPSO                          0   4   377    20   -343ns[ -343ns] +/-  112ns
#? PPSO                          0   4     0     -     +0ns[   +0ns] +/-    0ns

And the Chrony refclock configuration that produced those results (for demonstration 
purposes, no precision/delay/offset options here, so the "Last sample" 
measurements are undisturbed):

refclock SHM 0 refid GPSH
refclock SHM 1 refid PPSH
refclock SOCK /var/run/chrony.gpsd0.sock refid GPSO
refclock SOCK /var/run/chrony.pps0.sock refid PPSO

Question 2:

The GPSD Time Service HOWTO seems to suggest using the socket interface for 
Chrony over the shared memory interface. Is there some advantage to the socket 
interface? Does Chrony handle it better somehow? They seem to be pretty 
comparable as far as precision and accuracy go.

Question 3:

Why does Chrony need the NMEA source at all, and why does the HOWTO suggest it's 
bad if it acquires falseticker status? I tested Chrony with PPSH and GPSO (which 
seems to be acting as a PPS source) each as the sole source, with no servers, and 
in both cases, Chrony seemed to be able to establish accurate time. This was after 
a fresh reboot in both cases, which meant the system clock was starting out 
>10s off (since no RTC).

Thanks,
Nick