Re: Questions about GPSD as a time source with Chrony

[Gary E. Miller]

Yo Dominick!

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

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

A common request, except we are more fans of NTPsec...

> For some background:
> - I'm running on 64-bit Raspberry Pi OS, based on Debian 11 with
> Linux 5.15.30.

Hopefully not with their version of gpsd.

> - The GPS is a u-blox MAX-M8Q over serial with PPS (one of the
> Uputronics boards).

Nice boards.

> - I'm running Chrony 4.0 from the OS repositories.

A tad old.  Chrony 4.2 is current.

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

A bit overkill.  You can control the port speed and framing from the
gpsd command line.  The defaults will work fine for you.

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

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

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

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

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

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpjYnbiZicn6.pgp
Description: OpenPGP digital signature