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: Greg Troxel
Subject: Re: Problems with gpsd under BullsEye
Date: Sat, 01 Jan 2022 13:12:22 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (berkeley-unix)

Don Rolph <don.rolph@gmail.com> writes:

> Dire Wolf 1.7 against libgps.so.23, gpsd 3.23.2, BullsEye: fails: floods
> with packets and never quenches the floor
> Dire Wolf 1.7 against libgps.so.28, gpsd 3.23.2, BullsEye: fails: floods
> with packets but quenches after about 101 packets

A few points:

  gpsd 3.23.2 does not exist, but I think you mean "built from recent
  git master", which this minute has 242 commits after 3.23.1.

  libgps is built from gpsd, so using libgps.so.23, which was presumably
  built with some much older gpsd, is not the tested path.  Yes, it
  should at least mostly work, as in the situation where a machine with
  one gpsd version runs a program that gets data from a machine with a
  different version.  Therefore, if there's a bug in libgps, you should
  be testing with 3.23.1 or newer, as gpsd isn't going to pay attention
  to bugs in older releases.  However, I see your point that the
  behavior seems to follow gpsd version.

  I am surprised at libgps.so.28, because libgps_version_current is 29,
  in both release-3.23.1 and current master.  I have libgps.so.29 on my
  (NetBSD) system with 3.23.1 release installed from pkgsrc.  So I
  wonder if you have libgps.so from gpsd 3.22?

  You are talking about flooding, but can you show a trace of what is
  being emitted?  If it's 2 packets per second without a fix, saying
  there is no fix, that doesn't sound incredibly broken.  If it's 1000
  packets per second, and you can reproduce that with something that
  just connects to gpsd, and doesn't involve direwolf, that would reduce
  greatly the scope of the issue, which would greatly help in getting to
  a fix.

  Are you saying that gpsd is emitting so much data that direwolf is
  spending 100% CPU time reading and discarding the data?  Or do you
  perhaps mean "direwolf only expects 1 packet per second and if there
  are more they build up"?  I don't really mean to suggest that, as to
  put out a strawman for correction.  I've mostly read this thread, and
  I really don't precisely understand what's happening.   Perhaps a log
  of messages received with timestamps?

  Saying 3.17 works, 3.23.2~dev does not work, might be accurate, but
  unless you want to bisect the 5362 commits, it doesn't really lead to
  knowing what's wrong.  And it doesn't show where the bug is, as
  sometimes valid bahavior in software exposes a latent bug in some
  other software, so "update A, A-B system breaks" does not prove A is
  buggy.  (I'm not presuming anything about where the problem is.)

Attachment: signature.asc
Description: PGP signature


reply via email to

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