[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Questions about GPSD as a time source with Chrony

From: Dominick C. Pastore
Subject: Re: Questions about GPSD as a time source with Chrony
Date: Mon, 4 Apr 2022 22:27:38 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

Hi Gary,

On 4/4/22 9:17 PM, Gary E. Miller wrote:
Yo Dominick!

On Sat, 2 Apr 2022 23:33:14 -0400
"Dominick C. Pastore" <> wrote:

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:

And what were you expecting?  And what are you seeing?  gpsd has
more than one socket interface, so I'm not sure what you are thinking of.

The NMEA socket seems to be
passing PPS data, and the PPS socket isn't passing any useful data at

Without details, can't comment.

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?

Nope.  But SHM works fine.  No reason to do anything else.

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:

Hard to comment without seeing how you configured it.

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

The above 3 a godd.

Pardon? (My best guess is that line was supposed to read, "The above 3 are 
good," but I don't want to assume.)

refclock SOCK /var/run/chrony.pps0.sock refid PPSO

What said to do that?  chonry.gpsd0.sock is obviously your PPS, note the
good 120 ns jitter.  That is what you want.  All done.

The GPSD Time Service HOWTO did. Specifically, it said this:

"To get chronyd to connect to gpsd using the socket method add the following 
lines your chrony.conf file. Except, replace XXXX with the basename of your device’s 
serial port, often ttyS0, ttyACM0, or ttyAMA0. Replace YYYY with the basename of 
your PPS device, usually pps0.


# set larger delay to allow the NMEA source to overlap with
# the other sources and avoid the falseticker status
refclock SOCK /run/chrony.XXXX.sock refid GPS precision 1e-1 offset 0.9999
refclock SOCK /run/chrony.YYYY.sock refid PPS precision 1e-7

So you have both SHM and the socket file working.  I don't see any

Then I don't have any problems, but it seems the GPSD Time Service HOWTO might. 
It sounds like the suggested configuration for the socket method is incorrect, 
unless I am misunderstanding something.

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?

No.  Just the opposite.

If by "just the opposite" you mean there is a disadvantage to the socket 
interface (as opposed to merely no advantage), that begs the questions: 1) Why is the SHM 
interface better, and 2) should the HOWTO reflect that reality?

Why does Chrony need the NMEA source at all,

PPS is just that, a pulse.  NMEA is required to know which second the
PPS refers to.  But the NMEA and PPS info are combined, and written
tino the sock.gps0.socket.

and why does the HOWTO
suggest it's bad if it acquires falseticker status?

"falseticker" means "bad time".  If you do not care about good time, then
no problem.

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.

Yes, when things work, they work.  But there are many things that
can go owrong.

This was after a fresh reboot in
both cases, which meant the system clock was starting out >10s off
(since no RTC).

Normal.  But a reboot is not a total reboot.  For a real "cold start"
you need to power down.

I appreciate the responses.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]