Re: [gpsd-dev] [PATCH] Fix on NMEA driver 2D mode

[Eric S. Raymond]

José Miguel Gonçalves <address@hidden>:
> >What's your expected gain from reducing the sentence set?  You haven't
> >given me a good reason to support that yet at the cost of
> >reduced bulletproofing, but perhaps there is one.
> 
> I mainly work with low power and low processing embeded systems, so
> I normally need to spare every CPU resource that I can. Because of
> that I normally set my GPS receivers to output only the messages
> that I need to process.

I thought this was going to be the answer.  And what I tell you in
reply is: don't worry about this.  Even on low-power ARMs, the
processor utilization of the whole serial-device-to-GPSD-to-application 
pipeline is so low that it doesn't break the noise floor of the
processor-usage profiling.  This has been measured - and it was
negligible even before we went to pselect and got rid of the timeouts.

The overriding fact is that gpsd spends almost all its time in a
select wait.  The bandwidth utilization of the NMEA reports is so
small that at 9600bps and up you can't win anything measurable by
pruning sentences.

I understand the perfectionist drive to reduce traffic to a minimum
but in this case it doesn't gain you anything you will ever be
able to measure.

> I think that we can yet be on the safe side and solve this problem
> aroused with PolaRx2 if we change the test to;
> 
> ((session->newdata.mode < MODE_NO_FIX) || (session->newdata.mode > MODE_2D))

I'll look at it.  I might make such a change if only to bulletproof the 
code against obessive microtweakers. :-)  But not until after 3.5; I'm
very wary of potentially destabilizing code changes in that driver
especially.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>