gpsd-dev
[Top][All Lists]
Advanced

[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 15:34:47 -0700

Yo sean!

On Mon, 21 Sep 2020 18:26:46 -0400
"sean d'epagnier" <seandepagnier@gmail.com> wrote:

> I am using gpsd on a raspberry pi zero w.   This is a long standing
> issue with no resolution:
> 
> 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.

> 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,

News to me.

> 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.

> My other issue is with autobauding.   It was claimed the baud could be
> detected in 1 second, but this does not seem to be the case.

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.


> gpsctl
> -f takes 3-4 seconds even if the baud is set correctly, and if not, it
> takes 15, 28, or maybe it just hangs for 5 minutes until I kill it and
> it never finds the baud rate.

It can take longer than 5 minutes on pathological cases.

> The same behavior occurs with gpsd or
> gpsctl -f.   In the code it does not seem to have a timeout to detect
> the baud rate.   Maybe this worked better in older versions of gpsd?

It worked different on older versions.  It failed quickly on older versions,
now it detects more receivers.

Why do you not just set the speed correctly and be done with it?

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

Attachment: pgpKPRCUQhLCP.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]