Re: gpsd autobaud and cpu usage

[Gary E. Miller]

Yo sean!

On Fri, 25 Sep 2020 19:43:39 -0400
"sean d'epagnier" <seandepagnier@gmail.com> wrote:

> I ran a few more tests today.

Cool.

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

As expected.

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

I use 19200 a lot.  28800 is not in the hunt loop.  The autobaud starts
at the last used speed, so that depends on the state of the port before
gpsd starts.

> So it seems the autobaud does work but is slow.

Yup.  remember autobaud not only needs to check different speeds, abut also
different framing.  That is a lot of combinations to check.

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

8 speeds, times 2 seconds per test, times 3 parity (E, N, O) times
1 stop bits (0, 1, 2).  So that is at 144 seconds.   Plus flush()
time and settling time and time to see the start and end of a complete
message.

As noted in the code, USB adapters take a long time to change their
speed and start returing good data.

With DOS this was easy, but POSIX and Linux do not report framing
errors or buffer overruns.  Thus the need to get an entire message
decoded to know you have the right speed and framing.

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

As I previously quoted from the man page pselect() is select() is
poll().  The major difference is the order of arguments.  They all wait
the same way.  There is no point changing between them.

To save you reading the man page:

    "poll() performs a similar task to select(2): it waits for one of a
    set of file descriptors to become ready to perform I/O."

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

pgp3Np84mUf8F.pgp
Description: OpenPGP digital signature