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

[Greg Troxel]

"Gary E. Miller" <address@hidden> writes:

> Greg Troxel <address@hidden> wrote:

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

Time quality as you think about it does not matter here.  If we could
sync to within 50 ms, that is completely good enough.  We are talking
about lining up a ~13s transmission window and a 2s guard time with
other stations.  People who set their computers manually to WWV can
succeed.

I was mostly kidding about BeiDou/Galileo, but redundancy for bad
skyview is good.  It's also good in terms of a failure of the GPS
system, assuming that one of the other constellations is still ok.

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

Indeed, but I am trying to help organize a path for normals, and "take
your system you installed, and then hand compile the latest version of
all 2500 packages because each of them has new releases with bugs fixed"
does not seem like a good path to success!

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

Certainly; I get it that you don't care for systemd, and it seems pretty
clear that the default situation I found is not good.  But again, normal
people install Ubuntu, and I'm trying to figure out a good path for
them.

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

So I really have to ask: why is gpsd's default behavior of waiting until
open useful, for who, compared to the harm it causes?

I plugged in a GPS mouse, to a mac (no systemd there), and didn't start
gpsd.  I got a solid red light, and about 50s later (indoors) got
blinking.  This is all without DTR.  Actually it happened without a
prolific driver even loaded.  So just with power.  I pluggd the device
into USB power, no computer (Anker lighter socket adaptor), and it
started pulling 7-10 mA, and also started blinking.  So declining to
open it does absolutely nothing useful.

I can believe there are devices where it's useful.  But I wonder if
anyone here actually has one?

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

Well, I don't know enough to write it.  But certainly, it should be
explained.

At the very least, it should be explained that on systems with systemd,
there's often something listening on gpsd's port, and that one must
deconfigure gpsd from it.  And not just 'service stop', but how to make
it on future boots.  This probably ought to be a pointer, but the HOWTO
reads as if this problem does not exist.

Then there's how to start gpsd on boot, in such a way that hotplugging
works.  The gpsd documentation talks about autmoatically doing the right
thing and the wonder of hotplug scripts, but that obviously did not work
for me.

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

I realize that's per-OS/distribution dependent.  But the HOWTO could
outline the approach so that someone who isn't gpsd-clueful could
implement it in the distribution.

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

I know the maintainer of this one.  But he has never run gpsd, and I 


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

I don't get this.  I see it as pretty easy:

  - make the -n behavior default

  - leave -n as noop to not break scripts

  - add -w for the old behavior, and the theoretical people that
    actually want that can add it

How many people/systems are there that actually benefit from the -n
behavior?  Does this matter on Android?

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

I am seeing fuzz of a few milliseconds.  I call that success; you may
call it failure, depending on which accuracy requirements we have in
mind.

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

I looked at the hardware list and failed to come up with a "buy this
part number which is in current production in the USB GPS mouse form
factor".  There were two things that seemed usb-ish and had PPS listed
and both were 404.

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

I'm going with stratum 5 for now.