Re: [gpsd-dev] gpsd using excessive cpu

[sean d'epagnier]

Gary,

Thanks for the reply.

I am using linux 4.0.8 but also had this with 3.11 kernel.  The driver
used is SiRF.

 I don't see a problem with handling every byte..  But what happens
between the pselect all and the next one, is really very slow.  Why it
can't just have a tight loop and stick the character in a buffer I
don't know.   Maybe it can sleep for the minimum possible time it will
take to receive enough bytes to do something of use.  I think 1
millisecond would be sufficient.

Maybe it is like you suggest returning even when there is not any
data.     Basically I was running gpsd without stopping it for 10 or
15 days while all the time and somewhere along the way it began using
a lot of cpu.   Restarting gpsd didn't help it which is how I was able
to inject this sleep and found it worked.  I think restarting the
computer would help but now I need to verify this.

In the meantime I will try to reproduce.

Sean


On 11/16/15, Gary E. Miller <address@hidden> wrote:
> Yo Sean!
>
> On Sun, 15 Nov 2015 10:45:19 +0200
> "sean d'epagnier" <address@hidden> wrote:
>
>> I have found that with a 1hz binary gps that gpsd is using up to 6%
>> cpu on my haswell processor.
>
> Ouch.
>
>> I found a solution to the problem:
>
> or not.
>
>> +    usleep(100000);
>
> That would be too much for all but the slowest GPS.
>
>>      status = pselect(maxfd + 1, rfds, NULL, NULL, NULL, NULL);
>
> Notice the pselect is only supposed to return when there is data
> available.  So either gpsd is not setting up the pselect properly
> or your pselect is broken.
>
>> From what I can tell, the pselect returns after every single byte
>> received,
>
> Which is what we want.  can you confirm it is only waking up on
> a byte received?
>
>> and there is a lot of overhead between it returning until it
>> is called again.   If it could buffer to return only when a complete
>> message is sent then it wouldn't use much cpu.
>
> We don't want that, we want timeing info from the start of the message.
>
> And we can't get taht if we wanted since there is no way the kernel can
> detect message boundaries.
>
>> Adding the sleep may not be the best solution, but it surely makes the
>> cpu usage drop to 0%
>
> There must be something else going on as your result is unusual.
>
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>       address@hidden  Tel:+1 541 382 8588
>