Re: gpsd autobaud and cpu usage

[Gary E. Miller]

Yo sean!

On Mon, 21 Sep 2020 19:29:10 -0400
"sean d'epagnier" <seandepagnier@gmail.com> wrote:

> On 9/21/20, Gary E. Miller <gem@rellim.com> wrote:
> >>
> >> gpsd uses 5% of the cpu just reading from a single gps.  
> >
> > I run on Raspberry Pi 3, and average 3% usage.  So something odd
> > with your setup.
> >  
> 
> This is about the same since the pizero is an arm6.

The RasPi 3 is not that much faster.  I never used the much CPU with gpsd on
a Raspberry Pi 1 either.

> In either case
> this cpu usage is way too high for what gpsd is doing.   I need all my
> cpu and more cpu uses more power and everything is usually solar
> powered.

Of course.

> >> The
> >> "pselect" call that gpsd uses never blocks and always returns 1
> >> even if there is no data.  
> >
> > That would be a bug in your C library.  pselect() s supposed to
> > block. 
> >> I realize this is due to bugs in the usb
> >> drivers,  
> >  
> 
> I have managed to get kernel panics in the usb serial module from
> plugging in a gps twice after hundreds of plug/unplug cycles.   I also
> managed to hard lock gpsd a few times if I try to open the same port
> gpsd is using despite the exclusive lock.   This also unbelievably
> seems to block data from being read from other serial ports not
> involved.   It's really difficult to reproduce any of these, and I'm
> trying to work around the issues.  I only get these cases after
> plugging and unplugging multiple usb serial devices at least a few
> dozen times each ( didn't count but at least 30 or more times)  and
> I'm able to avoid accessing (probing for other sensors) the devices
> gpsd uses which seems promising.

Ouch.  Clearly kernel bugs if you can get a kernal panic.

> >> but in other applications which use poll, this doesn't seem
> >> to be an issue.   If I insert nanosleep of 100ms after the call,
> >> the cpu usage goes down to 0.3% and does not seem to affect gpsd
> >> in other ways but I am not sure possible implications especially
> >> with higher rate gps (mine is 1hz)  
> >
> > That would break other things.  100 ms is way too long to sleep.
> >  
> 
> I made it sleep on only 0 byte reads and the cpu usage drops from 5%
> down to 3%.  I sleep on 1 and 0 byte reads and the cpu usage drops to
> 0.4% (which is probably where it should be)   Most of the reads are 1
> byte and there is a lot of overhead in using select as it has to
> iterate over all the theoretical fds in multiple cases (sockets,
> devices, control sockets)

Since you are using USB serial, you should never get 0 byte of 1 byte
reads.  You need to complain to the Raspi kernel people.

> Shouldn't gpsd be using poll instead and avoid all of this?   I think
> it would improve efficiency considerably.

pselect() is almost identical to poll().  pselect() is just a flaavor of
select(), and the poll() manpage says this:
        "poll()  performs a similar task to select(2)"

> > It never was.  Now that some GNSS receivers output 4K long messages
> > at 4,800 gpsd has to wait a long time on each speed.  Maybe gpsd
> > could check speedds quickly, then slower on a 2nd pass.
> >  
> 
> I think 2 passes would be great if this is true.

Patches welcome.

> I care mostly about
> sirf and nmea which can be detected quickly.

Sort of.  Some SiRF messages can be long.

>   It should detect the
> baud rates in a specific order to speed detection

It does that.

> and also on what
> baud is most likely:  38400, 4800, 9600, 19200, 57600 etc 

"Most likely" is open to debate.  To my taste gpsd already does.

> It seems on a pi anyway, it should be possible to detect multiple baud
> rate simultaneously using software serial ports though this may use a
> lot of cpu.

Lost me.  Patches welcome.

> I think once the baud and driver are detected they should be stored
> somewhere on a disk as a hint for future detections but I can script
> this externally to gpsd.

Which is so easy, why bother to do anything else?

> > It can take longer than 5 minutes on pathological cases.
> >  
> 
> I don't think it ever finds the baud in some cases.  I can wait a lot
> longer than 5 minutes.  I'll play with this some more.

I look forward to data from your experiments.

> > Why do you not just set the speed correctly and be done with it?  
> 
> I develop pypilot a free software sailboat autopilot and specifically
> using tinypilot which is an operating system based on tinycore linux
> on the pi zero.   I have no idea what kind of gps the user might try
> to plug in, but I want it to work if possible and faster auto
> detection is better.

We all want that.  No one yet has any idea how to make it better than
it is.

> I also noticed gpsd doesn't quote the timestamp specifically in the
> json message when a devices is activated from a control socket
> resulting in invalid json messages I worked around with:

What gpsd version?  Got a sample of the bad JSON?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpdZPlupmdQp.pgp
Description: OpenPGP digital signature