Re: [gpsd-users] How to get the best performance out of gpsd?

[Gary E. Miller]

Yo pisymbol!

On Wed, 14 Aug 2019 23:51:05 -0400
"pisymbol ." <address@hidden> wrote:

> I have a Python program that does the following:

Care to share the code?  Hard to debug something we can not see...

> - Spawns a process via multiprocessing that runs in a tight loop
> reading TPV reports and saves the latest reading to a buffer. I'm
> using the stream() API.
> 
> - I have two other threads that pick up this buffer periodically (it's
> actually threads that are timestamping two video streams via
> GStreamer at ~30fps).

It took years for gpsd to get the buffering right.  Many ways to fail...

> - The GPS NMEA strings are emitted at 10Hz

Which you will eventually find is pointless...

> What I'm finding is that my GPS reader process sometimes lags behind
> the frames.  Basically, I will see at times a second go by before my
> process drains all the reports to the current one.

See, harder than it looks.  What sort of CPU?

> This means I see
> several frames with the same latitude/longitude before the next frame
> gets updated. Obviously if the frames are emitted at 30Hz and the GPS
> strings are at 10Hz I would expect three or four duplicate
> coordinates every second. But it varies wildly.

I'm not sure why you would expect duplicates.  I would call that a bug in
your program.

> I suspect this is a scheduling issue. My process just simply isn't
> real-time and the scheduler doesn't allow my process to drain the
> reports fast enough (or recv is too slow?).

Yup, you got issues.

> However, one "fix" for this would be if I could get the last valid TPV
> report from gpsd without having to manually drain the stream myself.

Those are one and the same...

> Is this possible outside of opening up a raw socket to my device and
> parsing the NMEA strings myself (something I really don't want to do).

I don't see how that could work either.

My guess is you are doing something obviously wrong.  Your latency is
self inflicted, but with no source code no way we can help you.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  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_y70y6zwjP.pgp
Description: OpenPGP digital signature