[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
pgprmaRb0SiSQ.pgp
Description: OpenPGP digital signature
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, (continued)
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, Hal Murray, 2019/05/06
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, Greg Troxel, 2019/05/06
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, Hal Murray, 2019/05/07
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, Greg Troxel, 2019/05/07
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, Hal Murray, 2019/05/07
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, Gary E. Miller, 2019/05/06
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, Greg Troxel, 2019/05/06
- Re: [gpsd-dev] gpsd for time sync on Ubuntu remix too hard for normals - how to improve?, Gary E. Miller, 2019/05/06
[gpsd-dev] Best way to avoid systemd woes for NTP?, Greg Troxel, 2019/05/05