gpsd-users
[Top][All Lists]
Advanced

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

Re: Problems with gpsd under BullsEye


From: Don Rolph
Subject: Re: Problems with gpsd under BullsEye
Date: Sat, 1 Jan 2022 18:30:56 -0500

You said:

"> You will have to ask the code developer.  gpsd is a minor part of the
> code functionality and there are other bugs which need resolution.  I
> have been copying him on the emails.

This seems important to you, why not to them?  But I'll leave that to you."

I reply:

I am trying to finish packaging an appliance for doing a specific amateur radio task,  I therefore need a clean build. and I need it in the next month or so.  The code developer does not have this time constraint and is chasing some deeper algorithmic issues.

You ask:

"Better, but I'm still confused.  What "message queue"?  What is in it?"

I reply

I am still working on which message queue, who is managing it, and what is triggering the over run.  So I can tell you as a black box what the error messages say, but not what they mean yet.

You say:

"It is easy to rate limit gpsd, but also easy to have gpsd flood you.
Many knobs to tweak."

I reply:

It does not appear to be the rate of generating messages, but rather that it looks like  messages are being saved up until a gps fix is achieved and then dumped out all at once.  But again, I have weak tools to  piece together what is going on.

You state:

"I'm not looking for apologies, just data.  One message per second is to
be expected.  If you get fewer messages then you have no messages at
all, and thus no idea what is happening."

I reply:

when I provide incorrect data which is my fault, it can scramble the work of others so I always apologize when I understand that I was incorrect.

My sense is there is about 4 more hours of actual work to characterize the situation as best as is reasonable.  In particular I want to capture the gpsd messages when we have the message flood.  Part of the problem with gpsd 3.23.2 is that it floods about 1/2 the time, where as gpsd 3.22-4 flooded essentially every time.  But gpsd 3.22-4 is from my perspective dead, so I need to understand gpsd 3.23.2.  I keep poking.

Thanks for your patience with me.




On Sat, Jan 1, 2022 at 5:43 PM Gary E. Miller <gem@rellim.com> wrote:
Yo Don!

I'm having trouble separting my comments from yours, but I'll try.

On Sat, 1 Jan 2022 16:21:55 -0500
Don Rolph <don.rolph@gmail.com> wrote:

> Are we giving you all this help and the upstream code will not get
> fixed??"
>
> You will have to ask the code developer.  gpsd is a minor part of the
> code functionality and there are other bugs which need resolution.  I
> have been copying him on the emails.

This seems important to you, why not to them?  But I'll leave that to you.

> You ask:
>
> "I'm still waiting for a deinition of "high rate of messages"?
> Most gpsd clients consider that a good thing."
>
> I don't have a rate but it is fast enough that we are filling the
> message queue much faster than it can be handled and we are dropping
> messages due to an over filled queue.

Better, but I'm still confused.  What "message queue"?  What is in it?
How does it get filled?  What gets put in the queue?  How does it get
emptied?  Is this between gpsd and the Dire Wolf input from gpsd?  Or is
this after Dire Wolf grabs the lat/lon/alt/time from gpsd?

It is easy to rate limit gpsd, but also easy to have gpsd flood you.
Many knobs to tweak.

>  It looks like we have dropped
> something on the order of at least 100 messages during the transient:
>  I will try to get a count form a log file.

More important that the count, is the content and the rate.  Is this 100
over a day?  Or 100 over a second?  Are these just gpsd messages?  Or
gpsd and other stuff?

> You stated:
>
> ":> I can of course monitor the output of the
> > MT3333, but I have already been monitoring this and it basically is
> > the messages every two seconds. 
>
> Which would be very weird.  Most GNSS receivers default to a fix
> every second"
>
> You are correct and I am in error:  it is one message every second.
> My apologies.

I'm not looking for apologies, just data.  One message per second is to
be expected.  If you get fewer messages then you have no messages at
all, and thus no idea what is happening.

Is one message a second flooding your queue?  Why is this a problem?

> You asked:
>
> "> Thoughts on a command line client to capture output of gpsd into
> say
> > a log? 
>
> To see the raw from the MT3333, with gpsd running:  gpspipe -R
>
> To see the JSON from gpsd:  gpspipe -w"
>
> Checked and that looks like it will work.  Back with the data probably
> tomorrow.

Cool.

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


--

73,
AB1PH
Don Rolph

reply via email to

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