Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?

[Gary E. Miller]

Yo Greg!

On Fri, 03 May 2019 10:25:03 -0400
Greg Troxel <address@hidden> wrote:

> * introduction
> 
> [This is just where I'm coming from, not really relevant.]

Televant to you.  And to hams, and others, that keep needing
evern better time.  so good background.

> So, after saying my club should do this right, I had to volunteer to
> make it work.  I have a shiny new $20 multiconstellation receiver for
> FD use, so we can sync to BeiDou and Galileo too.

Note that adding BeiDou and Galileo to a good GPS fix will degrade
the fix and time quality.  It does give you some redundancy for
bad skyview.

> * -n, systemd
> 
> I installed "Andy's Ham Radio Linux", basically Ubuntu 18.04 on a
> 2008ish MacBook.  (I then installed "gpsd-clients", which wasn't there
> by default.)

Ugh.  Ubuntu client is 3.17.  Many bugs fixed since then...

> I see that systemd is listening on gpsd's port, and gpsd is not
> running.

Note that the systemd part is NOT from us, but from Ubuntu.  We have
no control over that POS.

> After killing gpsd and trying to start it, I realized systemd was
> listening.  So I did "service stop gpsd", and was able to run gpsd
> with -n, -N, -D, and /dev/ttyUSB0.  Then xgps reported a position.

We are well familiar with the nightmare of systemd sticking its
nose where it has no business being.  Not our fault, totally out of
our control, complain to Ubuntu.

My standard suggestion to the poor falks doomed to suffer systemd is to
not let it control your gpsd.

> But, I wonder if this is
> expected to work for NTP?  Without -n, it seems it will not work.

Without -n, gpsd wakes up only for JSON clients.  So you are SOL
with NTP. 

My standard suggestion to the poor falks doomed to suffer systemd is to
not let it control your gpsd.

> The Time Service HOWTO does not talk about systemd,

Yup. systemd is not part of gpsd, and using it with gpsd is not, at
least by me, recommended.  Especially for time service.  If you feel
some crumb should be thrown to the poor enslaved systemd users, then
feel free to send a doc patch.

>   add the shm lines to ntp.conf (easy)
> 
>   decide to avoid the hotplug scheme
>   tell systemd not to start gpsd
>   add a way to start gpsd with -n on boot or insertion

Sounds about right.  I would add to use the latest release gpsd.

> (Or build gpsd with timeservice=yes, but I'm trying to help people
> configure distributions easily without having to become gpsd experts,
> not asking them to build things from source.)

timeservice=yes is a hack for RasPi HATs, dont btoerh with it.

> Am I confused, or did I get this right?

We're all confused a bit, but I think you have a good handle on it.

> It should be easy for someone to setup up a system so that gpsd/ntpd
> works on boot.  I'm not sure of the way forward.

Sadly that is very distro dependent.  If you wanted to add an Ubuntu
18 specific section to any of the howto's that might help other people.
The few that actually RTFM.

> Ideally, particularly for a ham remix, but in general, things would
> default so that if one plugs in a USB GPS that has PPS, ntp would sync
> to it without extra config.

Way out of scope for us, but we try to help any distro maintainer that
is open to help.

> It seems that the main barrier to having this work is the defaulting
> to non -n.

I'm with yout there, but every time changing the default is brought
up there is much talk raised that in some cases it may cost embedded
systems a 100mA.

As a practical matter, prolly too late to change.

> While I know we look down on non-PPS time sync, being synced to 50 ms
> is vastly better than not being synced at all.  And, for operating
> FT8 off the grid, totally adequate.   It seems easy enough to
> calibrate out the usual delay when on the net and have a fudge
> configured for offline use.

Yes, for many, 50 mS is great.  But calibrating out the dealy is
much harder than it looks.  Many tried, all failed.  The problem is
the GPS emit variable length messages, after taking vaying lengths
of time to iteratively compute the PVT solution.

> Realistically, given the offset from the non-PPS sync, I don't see it
> being workable as a default.

Works for me.  better yet, splurge another $10 and get a USB GPS
with PPS.  I get about 1ms using USB GPS those.

> But it could be a high stratum with a
> 100 ms guess, so that it takes over with no other sources.  I realize
> this is likely controversial and for specific situations, so please
> take it as musing rather than recommendation.

Not controversial at all.  And way better than using the pool.

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

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

pgpsRAo2iOxla.pgp
Description: OpenPGP digital signature