Re: Problems with gpsd under BullsEye

[Gary E. Miller]

Yo Don!

On Sat, 1 Jan 2022 18:30:56 -0500
Don Rolph <don.rolph@gmail.com> wrote:

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

Since he is busy, and gpsd code clearly annoys him, will he just take your
patch and apply it to his upstream?

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

That would be a good step forward.  Please send them.

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

gpsd does not save up data past one epoch, which is usually one second.
So where might Dire Wolf be getting constipated?

>  But again, I have weak
> tools to  piece together what is going on.

fprintf(stderr,) is all you ever need.

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

Fair enough.  All I care is we agree on what is real and known.  You
are taking those steps too.

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

Or, just capture everything from gpsd, with a time stamp.  Then you
can go back to the time when things went bad.

Then you can cut/paste just the bad part, and replay it as ofen
as you want into Dire Wolf.  Then you get repeatable failure.

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

1/2 the time seems like a lot.  It is the once every 1024 week bugs that
drive me crazy.  Once you have a copy of the JSON that triggers the
bug, use gpsfake to replay as often as you wish.

> But gpsd
> 3.22-4 is from my perspective dead, so I need to understand gpsd
> 3.23.2.  I keep poking.

Please do.

> Thanks for your patience with me.

I expect good things to come from this.  Like Dire Wolf gets fixed.

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

pgpNGqg_fIGbS.pgp
Description: OpenPGP digital signature