Re: gpsd autobaud and cpu usage

[sean d'epagnier]

I ran a few more tests today.

38400 is one of the most common bauds after 4800, and it finally found
the right baud after 11 minutes and 20 seconds.  Before I didn't wait
long enough.

For finding 19200 it took around 5 minutes.   It should probably check
bauds starting with the fastest ones as they take less time, but 19200
or 28800 are probably not very common at all so could go at the end of
the list.

So it seems the autobaud does work but is slow.   I'm pretty sure with
two passes it could find the right baud in 20 seconds or less for the
most common cases, so maybe I'll attempt a patch.

I would like to switch from select to poll also but not sure I'm ready
to deal with all the changes needed so I'm keeping my nanosleep hack
in place to greatly reduce cpu.

Sean

On 9/21/20, 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.    The
> "pselect" call that gpsd uses never blocks and always returns 1 even
> if there is no data.   I realize this is due to bugs in the usb
> drivers, 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)
>
>
> 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.   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.   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?
>
>
> Sean
>