gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Best way to avoid systemd woes for NTP?


From: Gary E. Miller
Subject: Re: [gpsd-dev] Best way to avoid systemd woes for NTP?
Date: Mon, 6 May 2019 13:09:55 -0700

Yo Greg!

On Sun, 05 May 2019 11:28:09 -0400
Greg Troxel <address@hidden> wrote:

> I am trying to help a distribution maintainer (of an Ubuntu remix) set
> things up so that
> 
>   - install distribution
>   - boot
>   - plug in USB GPS mouse
> 
> will lead to gpsd being used as a stratum 5 server with an assumed
> offset of 80ms, in support of having time to within 100ms while off
> the grid.  I thus have a few questions, mostly systemd and the
> recommended avoidance path.

A couple of things.  If the gpsd/ntpd is attached to a GPS, then it
is Stratum 1.

Also, as Hal pointed out, 100 ms is a better goal.  Not jitter, 
accuracy.  You should test against a GPS PPS before you can know
you hit your goal.



> 0) Obviously ntpd needs a server line for the shm refclock.  That's
> clear and in the HOWTO.  (Hence not a question.)

"needs" is too strong.  ntpd has an NMEA driver.  But "prefers" 
absolutely.

> 1) It seems systemd does not invoke gpsd with -n, and I'm guessing I
> can change a config file to add this.  Can anyone report success with
> this?

There are many examples in the gpsd email archives.  That topic
comes up monthly.

> The troubleshooting page
>   http://catb.org/gpsd/troubleshooting.html
> gives an example of how to have systemd start gpsd at boot rather than
> on a connection, but the example does not pass -n.

You misread that.  That shows systemd grabbing port 2947, but only
launching gpsd on connection to port 2937.

If you get a better example, I'll change that file.

Look in the gpsd email archives.


> 2) The example gives a chrony line for sequencing, but not ntpd.  The
> ham remix at least uses ntpd, so it seems both should be present.  Is
> this a correct conclusion?

No.  chrony OR ntpd.  Both try to use the NTP udp port and the SHM.
Either will work for you.  Obviously we prefer NTPsec here.

> 3) The example in the troubleshooting page does not pass a tty
> pathname, so I'm guessing that the udev/hotplug scripts are separate
> from the systemd part, and arrange to call gpsdctl to add the tty on
> insert.

Yes.  As documented in the gpsd source.  Look at gpsd.rules for the
udev rules to make the magic happen.

> Is this known/expected to work on Ubuntu?

Yes, known to work, badly documented.

> 4) Does the -n flag for the global gpsd become effective on individual
> serial ports added with gpsdctl?  If gpsd is started with no devices,
> and hotplug does gpsdctl add, does gpsd start running on the new
> device?

I suspect starting gpsd with -n would then keep any hotplu agged GPS
running all the time.  Worth testing.

> 5) I don't follow how the default setup works, in that the hotplug
> script should run on insert, and then gpsd only started when someone
> starts a client.  So with the following sequence:
> 
>   1) boot
>   2) systemd starts listening on 2947, no gpsd
>   3) USB GPS mouse inserted
>   4) user runs xgps
>   5) systemd receives connection, starts up gpsd

Step 3a) systemd starts gpsd.  

Step 3b) systemd can use -F, or gpsctl, to add the GPS.

> I don't see how the gpsdctl from step 3 works, because when gpsdctl
> starts gpsd, it will fail because systemd is listening on 2947.   Is
> this broken, or what did I get wrong above?

Well, I think systemd is broken by design, but it is smart enough to 
pass the 2947 connection to the new gpsd.

> 6) If the recommendation is to totally avoid systemd for gpsd, what
> should I do instead?  (Keep in mind that my goal is reliable operation
> with minimal changes.)  Should whatever that is be explained in the
> troubleshooting guide?

For those stuck on Ubuntu, most start out trying to get systemd to
work.  Some succeed.  The rest get mad, delete the systemd/gpsd service,
then start gpsd with a bootup script that uses -F and udev.

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

Attachment: pgprmaRb0SiSQ.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]