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

[Adam Serbinski]

I accidentally sent this directly, when I would have replied to the list, so 
here it is again.

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

The reality of the situation is that systemd is NOT itself the problem.
While it can be a challenge to maintain and configure, it CAN be configured
correctly. That's really just a matter of getting your configurations
correct.

Now does "distro X" supply gpsd with systemd configurations that work? To
some extent, but not necessarily the way that you want them to. That isn't
systemd's fault, that's the distro maintainer's fault.


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

Whether or not it is default behavior doesn't really matter. You just need
to set the configuration so that it uses the configuration that makes sense
to you. Most distros do NOT assume that you have a GPS installed on your
machine for time. In fact, the chance of that is so low that they really
aren't interested in worrying about it. Does your distro even install gpsd
by default? Probably not, you probably have to install it yourself.

Now the problem with the -n parameter, is that it causes the gps device to
activate, and activating it means increased power consumption. Setting the
defaults to increase power consumption is probably not the ideal default
configuration.

Which is why its a nice thing that most distro packaged gpsd will have a
file in which you can specify the parameters to use. Fedora, for example,
has a configuration file at /etc/sysconfig/gpsd


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

Virtually *ALL* embedded GPS's will default to off or low power
consumption. Many/most U-blox GPS's (many are available with USB
interfaces) have low power modes. Whether a particular one is configured to
default to a low power mode or not is something you will need to look at
with that particular unit, but such configuration can be saved.


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

Systemd actually has a really... interesting... ability to start a service
upon a socket connection. So when gpsd is not running, but something seems
to be listening on its port, that is actually "gpsd.socket". When
gpsd.socket has a connection, it starts up gpsd and switches the socket
over to gpsd.

So the way that the distro default is going to work has it that gpsd.socket
runs by default, but gpsd itself does not. So obviously that isn't going to
work for ntp. But if, on the other hand, you start up xgps, then gpsd will
start up on demand.

Doing this is not in any way wrong, for their objectives. Unfortunately for
you, this objective is not consistent with YOUR objective.

BUT, you can get to your objective fairly easily from the distro defaults.

Now I don't use Ubuntu. I use Fedora.
In Fedora, getting to where you want to get can be done like this;
1) dnf install gpsd (which, BTW, comes in with 3.18.1)
-- that will install gpsd, and enable gpsd.socket, BUT NOT gpsd.service.
2) systemctl enable gpsd.service
-- you don't have to disable gpsd.socket, since it is meaningless if gpsd
is actually running.
3) edit /etc/sysconfig/gpsd to add the specific parameters you need, like
"-n /dev/ttyACM0".
4) Add this line to /etc/chronyd.conf:
refclock SHM 0 refid GPS precision 1e-1 offset 0.9999 delay 0.2

And that's all that is needed to have chronyd fed by gpsd automatically on
system boot.


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

Anybody who needs to save power.
Android... -n is probably a VERY BAD idea, since most Android devices run
on battery.