gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Gary E. Miller
Subject: Re: [gpsd-users] How to get the best performance out of gpsd?
Date: Thu, 15 Aug 2019 13:14:37 -0700

Yo pisymbol!

On Thu, 15 Aug 2019 07:24:18 -0400
"pisymbol ." <address@hidden> wrote:

> On Thu, Aug 15, 2019 at 12:50 AM Gary E. Miller <address@hidden>
> wrote:
> 
> > 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...
> >  
> 
> Sure, no problem.

Uh, where is it?

> > > - The GPS NMEA strings are emitted at 10Hz  
> >
> > Which you will eventually find is pointless...
> >  
> 
> I think understand why, but can I hear it from you Gary?

I don't have a 10Hz receiver.  Just what I hear from everyone that
tried: too much averaging, plus some delays.

> > > 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?
> >  
> 
> Jetson TX2 (four ARM cores). But it's an embedded platform and
> recording 4k video from two streams to boot!

A tad old, and on the under-powered side, but prolly OK, if the video is
handled by the GPU, not the CPUs.

> > I'm not sure why you would expect duplicates.  I would call that a
> > bug in your program.
> >  
> 
> 
> No, it's simple math:
> 
> 10Hz -> Trimble
> 30Hz -> Frames
> 
> I am emitting frames faster than the Trimble can emit a NMEA, hence I
> will always have duplicates (3-4 per second ideally).

You are creating the duplicates, not gpsd.

> Of course, that's not what I'm seeing exactly. Sometimes I see a lot
> of duplicates.

And once again, without seeing your code and data no one else can
comment concretely.

> > Yup, you got issues.
> I know, but I talk to my wife a lot. She's a big help.

Good thing you did not marry my ex-

> > Those are one and the same...
> What I mean is this:
> 
> 
> In [20]: g.next()
> Out[20]: <dictwrapper: {'mode': 3, 'ept': 0.005, 'class': 'TPV',
> 'lat': 41.671886859, 'speed': 0.007, 'lon': -93.718452103, 'alt':
> 254.479, 'track': 124.635, 'eph': 19.0, 'time':
> '2019-08-15T11:05:22.000Z', 'status': 2, 'climb': -0.05, 'device':
> 'tcp://192.168.142.1:5017'}>

I have no idea what that means.  Without the code it has no context.

Some gpspipe, captures might help.

> I am waiting seconds before each manually g.next() call but I still
> see the buffered NMEA string - not the one that just arrived.

Duh.  Why are you waiting?  Don't do that!

> Please
> see the 'time' field. It's clear that gpsd buffers these samples.

Duh.  Only because you force it to.  Don't do that!

> Can
> I turn that off in stream mode?

No.  Nor should you.

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

Lost me.

> I sure hope so.  But here's hopefully a readable sample:

"readable" does not help.  You call important code that you do not show.
Some things look really wrong, but hard to tell. "runable" is what we
need to see what you do wrong.

> The nmea, nmea-lock, and control structures are managed by
> multiprocessing.

You realize that Python can not do multiprocessing?  That whole
Global Interpreter Lock (GIL) thing?


> 1) The nmea_lock is contentious

Duh.  Python is single threaded, and the GIL thing.

> 2) the trimble.next() call is sometimes slow (recv() call from
> gps.py/read() sits there too long as the Trimble fills the socket
> buffer)

No.  The buffer fills when you do not read it.  If you read it then
it does not fill.


> 3) The system is overloaded so the scheduler just can't give this
> process enough time slice to keep up (hence why I tried the
> os.nice(-10))

Could be, but that would be your problem.  gpsd only takes a few
percent of CPU on an old RasPi.

Did you check the load factor directly?

> 4) The Trimble unit is not really emitting these sentences even close
> to 10Hz

Once again, gpspipe will have the answers.

> 5) I have a bug in my crappy code above. I sure hope so! Would make
> my life a lot less stressful.

That is my assumption.  My bet is that xgps and cgps work just fine
on your TK2.

But no way to tell without running code.

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

Attachment: pgp2Nb1ZUxVbq.pgp
Description: OpenPGP digital signature


reply via email to

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