Re: Questions about GPSD as a time source with Chrony

[Dominick C. Pastore]

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" <dominickpastore@dcpx.org> 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
> > all.
>
> 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
> problems.

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.
>
> Yes.
>
> > 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.

Thanks,
Nick