Re: [gpsd-dev] OS X dropped. How I think about our platform priorities

[Eric S. Raymond]

Gary E. Miller <address@hidden>:
> BTW, I have spent time combing the binaries on my Android phone and
> fgrepping the AOSP source.  Do you have evidence for you claim of
> gpsd in Google Maps?

Yes.  I've found bug reports referring to gpsd on Android developer forums.

The main unknown isn't whether gpsd is in Android phones, it's when it
was introduced there. I don't have direct evidence back past 4.0.
(And when they started using it is something I'd really like to know!)

In 2013 there was a rash of problems with excessive power drain on a
couple of Samsung Android phones that some Android devs thought were
down to a GPSD bug.  gpsd showed up as the power-eater.  

The workaround was to purge some apps that were running in background
but requesting "Detailed Location", which is apparently the Android
system setting that brings gpsd up to watch the GPS.

Google Maps uses "Detailed Location" (but doesn't run in background).

More detailed account here:

No, GPSD is not the battery-killer on your Android!
    http://esr.ibiblio.org/?p=4886

There are confirmations from Android devs in the comments.  One of them
popped up in my comments a couple hours ago to ask when the version
with anti-buzz fixes would ship.

I thought, from the symptoms, that gpsd was spinning too fast due to a
bug in select(2). I still think that's the most likely cause - the bug
was too sporadic and limited to a handful of phones to be a
cross-platform GPSD fuckup, and we had already seen broadly similar
misbehavior on the Mac from buggy PL2303 drivers.

However, the possibility that gpsd was behaving worse than it should
in the presence of buggy serial layers has been bothering me ever
since.  That's why I jumped on the adaptive-delay idea when some
random RaspPi hacker showed up on #gpsd complaining about what seemed
to be the same problem.  And it's why I persisted in trying to switch
to blocking I/O after adaptive-delay didn't work out; it's the
motivation for 3.12.

Most likely the reason you didn't find gpsd in AOSP is that they've
integrated proprietary AGPS code and don't drop the resulting source
with AOSP.  This didn't annoy me until I found out AGPS has
standardized interfaces from the cell radios; now that I know that I
want that code back upstream, here.

> In looking at the AOSP source, Google goes to great lengths to avoid
> floating point math and goes to some lengths to special case their
> longer integer math.  This is to cover for the lack of FPUs in most ARM
> variants.

I know.  That's why there's a NOFLOATS in the GPSD build; it basically
disables the error modeling, which is where almost all the float
computation goes on.  I put that in there for the ARM folks before
I found out we're on Android.

It worked, too. I've been on IRC with guys developing for lower-power ARM
on SBCs who told me that with NOFLOATS on their CPU utilization is below
the noise floor of the metering. :-) 

> If embedded ARM is truly a focus, then purging as much floating math as
> we can fro gpsd might be a goal.  It would be interesting to hear from
> some knowledgable embedded parson on the topic.

You're welcome to make a pass through the code looking for this.  I
think about the only use left outside of error modeling and optional
profiling is one computation per second for a float time to be
returned in struct gps_fix.

In general, I don't think float overhead is as urgent an issue for
GPSD as it is for most apps, simply because the GPS data rate is so
low.  Even an ARM doing FP emulation can afford a few dozen FP ops a
second; they only start to be a problem at hundreds or thousands.

Oh, and another unknown is whether iOS also uses GPSD.  I've seen some
hints that they do, but Apple plays these things much closer to the 
vest and I'm not sure.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>