[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gpsd autobaud and cpu usage
From: |
Gary E. Miller |
Subject: |
Re: gpsd autobaud and cpu usage |
Date: |
Mon, 21 Sep 2020 17:52:09 -0700 |
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