Re: gpsd autobaud and cpu usage

[Gary E. Miller]

Yo sean!

On Fri, 25 Sep 2020 22:27:12 -0400
"sean d'epagnier" <seandepagnier@gmail.com> wrote:

> yo gary!
> 
> > 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.  
> 
> ah, it should probably start at the higher speeds and work its way
> down as they would finish faster anyway.

Still have to wait several seconds on each speed/framing combo, so not
much of an improvement.

>  Of course trying the current
> speed first.

As it currently does.

> > 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.  
> 
> Hmm.   I've never heard of any gps that uses something besides 8n1.

Trimble.  And it is very picky about it.

> So perhaps it could do 1 stop bit without parity over all speeds
> first.

Which might almost be the current scheme.  Needs checking.

> > 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 didn't realize this either but makes sense.

The rabbit hole is deep.

> > 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.  
> 
> This is not strictly true.   When select returns, you have to iterate
> over the fdset and up to maxfds testing every one for bitmask of if
> the flag is set.  This is a large number.

Not a large number.  Maybe one two or three.  Lost in the time that
any system call takes.  All the new trampoline code and cache flushing
makes system calls much worse than before.

Feel free to code up poll() and benchmark it.  I bet you can't tell
the difference.  If you do see a difference then send us the patch.

> In the code gpsd does this
> in at least 3 different cases, one for sockets, one for devices, and
> another for control sockets.   This is quite a lot of overhead for
> common single byte reads and is the reason the cpu usage is 3 (or 5%)

Single byte reads are not common at all.  Never on USB or JSON reads.

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

pgp_Y7JoxGzgc.pgp
Description: OpenPGP digital signature