Re: [gpsd-dev] gpsd using excessive cpu

[sean d'epagnier]

I don't know if it's reasonable to measure cpu usage to determine if
there is a bug in the drivers.

I think the simplest solution which I can't see any downsides to is to
simply sleep for 10ms if pselect returns without any data.  What do
you think?

Sean

On 11/18/15, Jon Schlueter <address@hidden> wrote:
> one approach would be a dead time delay if we received fewer
> than X bytes delay by long enough to get X bytes next time.  I
> think there were attempts at this a while back on this list.  try
> searching through the archives.
>
> but a sane approach if you want a workaround would be 1-50 ms
> sleep at the bottom of the read loop.  this would give it a reasonable
> balance between snappy receives and not getting behind.  Too much
> and gpsd get's behind because it needs to read multiple messages
> per second, to little and it burns CPU if you have the bug in the
> underlying drivers.
>
> Jon
>
> On Tue, Nov 17, 2015 at 3:14 PM, sean d'epagnier <address@hidden>
> wrote:
>
>> Now, I am trying to reproduce it, but not having much luck.
>>
>> I have always seen this problem appear when I'm on passage.  I notice
>> gpsd is using excessive cpu.  At this point I am somewhere in the
>> ocean far from land and have been sailing 10-15 days and gpsd running
>> the whole time.  I am traveling 4-5 knots on average.  When I
>> restarted gpsd it immediately consumed too much cpu, so to me this
>> shows it is possibly a bug in the serial layer not gpsd as raymond
>> suggested.   I will leave my computer running for a few days to try to
>> reproduce, but after only 24 hours I don't see the problem yet.
>>
>> Sean
>>
>> On 11/17/15, Eric S. Raymond <address@hidden> wrote:
>> > sean d'epagnier <address@hidden>:
>> >> Maybe it is like you suggest returning even when there is not any
>> >> data.
>> >
>> > This has been seen on certain models of Samsung smartphones.  It can
>> > happen if there is a port bug in the Linux serial layer.
>> > --
>> >               <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
>> >
>>
>>
>