[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions about GPSD as a time source with Chrony
From: |
Dominick C. Pastore |
Subject: |
Questions about GPSD as a time source with Chrony |
Date: |
Sat, 2 Apr 2022 23:33:14 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 |
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
- Questions about GPSD as a time source with Chrony,
Dominick C. Pastore <=