Re: [gpsd-dev] [PATCH] Fixes various flakiness in PPS handling.

[Fred Wright]

On Wed, 28 Sep 2016, Gary E. Miller wrote:
> On Wed, 28 Sep 2016 17:03:17 -0700 (PDT)
> Fred Wright <address@hidden> wrote:
>
> > > It solves a real problem for RasPi and BeagleBone users.  Any change
> > > now would break a lot of HOWTO's and existing systems.  I'd consider
> > > a patch to implement an opt-out option.
> >
> > You still haven't answered the question of what that "real problem"
> > was, and neither the comments nor the commit message provide any
> > documentation.
>
> I thought is was well documented when Eric added that 'feature'.  Most
> users could not figure out how to add /dev/pps0 to the gpsd commandline,
> or even worse how to get systemd to do so.

By "documented" I mean explaining the details of the problem it was trying
to solve.

In order to get gpsd to work at all (in these contexts), users have to put
certain options and the device name of the serial port on the command
line.  Are you seriously claiming that they can figure out how to do that,
but can't figure out how to include /dev/pps0?  That makes absolutely no
sense whatsoever.  What *does* make sense is that they were putting it on
the command line but it wasn't working.

With releases earlier than 3.15, PPS on the command line wasn't supported
at all.  Although it wasn't actually harmful, the log messages related to
the attempts to treat it as a serial port might be misinterpreted as
trouble.  That wouldn't provide any actual PPS, of course.

>From 3.15 onward, but without the fix in this thread, it would attempt to
work but typically screw up.  Specifying the PPS device explicitly doesn't
stop it from trying to use the line-discipline PPS device associated with
the serial port, so it winds up with two PPS threads, one of which is
useless but theoretically harmless.  However, due to the initialization
bug, the two threads would step on each others' toes, and generally wreak
all manner of nonreproducible havoc.

With the MAGIC_HAT kludge, the assumed GPIO-based PPS is used *instead
of*, rather than *in addition to*, the modem-line PPS, so the collision
doesn't happen, and the source actually works.  So the real benefit of
MAGIC_HAT was in avoiding *code* screwups, not *user* screwups.  Note that
this was actually the second pot-shot "fix" for the initialization bug, in
lieu of tracking down the real problem (the first being the static
inner_context).

> So Eric made that an autodetect.  It solved a huge support issue.  Now
> it is documented and referred to in a lot of third party doc.  Not gonna
> step that change back, this is way better than before.

I'm not sure what "a lot of third party doc" you're referring to, but the
ones I've found (including the two linked from INSTALL) specify obtaining
gpsd via apt-get.  Since that can only provide release versions, and since
MAGIC_HAT has never been in a release version, many, if not most, users
have never even used the version of the code that has it at all.  Only
users that get sources from the git repo and do their own builds can
possibly have used it.  And the notion that someone can manage to do all
that and still not be able to put /dev/pps0 on the command line extends
even further into the realm of absurdity.

That does beg the question of why MAGIC_HAT helped at all.  Most likely,
it's because the *assumption* of MAGIC_HAT caused the instructions to stop
specifying /dev/pps0 on the command line, thereby avoiding the problems
that it caused.  Although it never caused any *real* problems prior to
3.15, at the high debug level recommended by the instructions (even
without actually seeing trouble), one sees a bunch of messages related to
its attempts to use /dev/pps0 as a serial device.  It eventually gives up
on that harmlessly, but the messages may look like trouble to someone not
familiar with the internals.

Without MAGIC_HAT, not specifying /dev/pps0 on the command line means that
gpsd doesn't get a PPS source, but that's actually mostly harmless.  The
instructions for configuring NTPd normally specify getting the PPS data
directly from the PPS device, so it doesn't actually matter for time
service purposes whether gpsd sees PPS at all.  It's useful if one wants
to monitor the PPS behavior via gpsd tools, but NTPd doesn't care, and
users who've never seen the PPS info in the gpsd tools are none the wiser.

Note, for example, the gpsd page in the Adafruit setup instructions:

https://learn.adafruit.com/adafruit-ultimate-gps-hat-for-raspberry-pi/use-gpsd

You can clearly see that gpsmon is not seeing PPS data.

> > It certainly never helped Beaglebone users using the only
> > off-the-shelf GPS cape that's available, since it's incompatible with
> > the kernel provided by the vendor.
>
> Well, you'll have to explain that a bit better.  I have no Beaglebone.
> If it is ALWAYS a problem on the BeagleBone then maybe scons could
> detect the BeagleBone and do something different.

It's not about the Beaglebone specifically, it's about the kernel build
options.  The kernel in Yantrr's prebuilt Debian image includes the
synthetic PPS source at /dev/pps0.

> > An opt-out approach makes sense as an interim fix that doesn't break
> > existing setups, but everyone should be strongly encouraged to opt
> > out and stop depending on it.
>
>
> No, it solved WAY too many problems.  The decrease in suport requests
> was very dramatic.

And probably as underanalyzed as the ppsthread bug. :-)

> >  Any HOWTO needs to include a section
> > on identifying the correct PPS device, since it can't be assumed to
> > be /dev/pps0.
>
> Actually, on the RasPi, it can be assumed.  And is there any harm in opening

No it can't.  If you don't believe me, build a Pi kernel with
CONFIG_PPS_CLIENT_KTIMER turned on and watch how badly your assumed
correct /dev/pps0 works.

> any pps?  If /dev/pps0 is not found, you just need to add the
> real /dev/ppsXX on the gpsd command line, just as before the
> autodetect patch.

There are a few reasons not to use arbitrary PPS sources in gpsd:

1) Some may be intentionally invalid time-synchronization sources, such
as the synthetic PPS from the kernel (intended solely for testing).

2) Some may be stable PPS sources that aren't synchronized to UTC second
boundaries, either because they lack the ability or because they aren't
currently so synchronized.  For example, many precision frequency
standards include PPS outputs, but may have no ability to discipline them
to UTC seconds.  And even when they have the ability, there's usually some
additional status that needs to be checked to determine whether they're so
synchronized, which is invariably by some means other than looking for a
"valid fix" in an NMEA stream.

3) More generally, gpsd is *gpsd*, not ppsd.  Handling PPS sources not
associated with GPS receivers is beyond its job description.  And as noted
above, it doesn't have a clue as to how to validate such sources, anyway.

Ideally, every PPS source used by gpsd should be associated with a
specific GPS device.  But there's no reliable automatic way to do that for
anything other than the modem-line case (which is the worst hardware
approach from an accuracy standpoint).  It's a deficiency that a
manually-specified PPS source can't be explictly associated with a
manually-specified serialport, but fixing thatrequires soke work on the
command-line parsing.

> > 1) If your GPS serial port is named something other than /dev/ttyAMA0
> > or /dev/gpsd0, then include the name of your PPS device on the
> > command line in addition to the serial device name.
>
> That breaks on RasPi.

Not any more.  Try it.

> > 2) If your GPS serial port is named /dev/ttyAMA0 or /dev/gpsd0 and
> > your GPS PPS device is /dev/pps0, then specify just the serial device
> > on the command line, and gpsd will add /dev/pps0 automatically.
>
> Well, it is not automatic if you have to specify it.  And that fact
> that people forgot to specify was a huge problem, now gone.

See above.

> > 3) If your GPS serial port is named /dev/ttyAMA0 or /dev/gpsd0 and
> > your GPS PPS device is something other than /dev/pps0, then rebuild
> > gpsd with MAGIC_HAT disabled, or create a symlink to the GPS serial
> > port that's named something other than /dev/ttyAMA0 or /dev/gpsd0 and
> > use that name instead, and specify both the serial device and the PPS
> > device on the command line.
>
> Rebuilding is not an option for the vast majority of gpsd users.

Which is exactly why building something that only works sometimes is a bad
idea in the first place.

> > Specify both the serial device and the PPS device for your receiver
> > on the command line.
>
> You can do that now.

Only if you don't mind possibly *also* getting a bogus PPS source that you
didn't ask for.  If you don't believe me, try it on a kernel with
CONFIG_PPS_CLIENT_KTIMER.

I think it's probably possible to add some code to blacklist the fake PPS
source (with yet another magic filename hack), but due to the way the code
is organized, it couldn't easily substitute a different device.


In any case, I think we can agree that the first step is to make MAGIC_HAT
a configuration option, initially defaulting to enabled.

Fred Wright