[Xastir] [Bug 454740] Re: xastir consumes CPU time in X11 socket I/O

[David Aitcheson]

On Tue, Jan 5, 2010 at 3:30 PM, Curt, WE7U <archer at eskimo.com> wrote:

> On Tue, 5 Jan 2010, David Aitcheson wrote:
>
>  FYI to group.
>>
>> Kamal, keep us in the loop.
>>
>> Dave - KB3EFS
>>
>> On Tue, Jan 5, 2010 at 2:32 PM, Kamal Mostafa <kamal at whence.com> wrote:
>>
>>  kjotte at zarya:~$ apt-cache policy xastir
>>> xastir:
>>>  Installed: 1.9.4-3
>>>  Candidate: 1.9.4-3
>>>  Version table:
>>>  *** 1.9.4-3 0
>>>       500 http://archive.linux.duke.edu jaunty/universe Packages
>>>       100 /var/lib/dpkg/status
>>>
>>> After upgrading from Intrepid (xastir 1.9.2) to Jaunty I noticed my CPU
>>> was
>>> running at a constant ~10%.  Running an strace revealed there was quite a
>>> bit time spent timing out of polls on the X11 socket fd.  I tried setting
>>> the DISPLAY to use TCP instead of UNIX sockets, but the high poll
>>> activity
>>> still occurred.
>>>
>>
> With a Firenet non-filtered full feed on this machine and latest CVS
> Xastir I'm seeing 1% CPU usage from Xastir.  This is using "top" set
> to do 30-second updates.  Firenet is the fastest feed I can hook up
> to.  OpenSuSE-11.1 64-bit Linux.
>
> --
> Curt, WE7U.                         <http://www.eskimo.com/~archer<http://www.eskimo.com/%7Earcher>
> >
>   APRS:  Where it's at!                    <http://www.xastir.org>
>  Lotto:  A tax on people who are bad at math. - unknown
> Windows:  Microsoft's tax on computer illiterates. - WE7U.
> The world DOES revolve around me:  I picked the coordinate system!"
>
> _______________________________________________
> Xastir mailing list
> Xastir at lists.xastir.org
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
>

Rambling thoughts...

I have to wonder if the CPU activity level is dependent on the package
version and/or the number of libraries called and/or cascade called and how
the hardware handles those calls.  I am aware of differences between
"IDENTICAL" machines that are severe enough to cause major timing issues
when used in parallel.  Even yocto second ( 10^-24 ) differences can be
deadly over time.  But luckily we do not deal in that realm here; and yes I
used to do work in a finite timing world.

Then there is the issue of some of the on board graphics chips being
somewhat dependent on the main CPU for some processing as they were designed
to be in the "Macrohard" environment.  This "GPU" load could be the source
of the perceived excess load on the CPU, maybe?

I'll have to see how my cpu use tracks.  The system is only partially set up
at this point and only Internet connected.  A GPS and TNC/Radio have yet to
be added.  I am waiting to see if someone attempts to sabotage things here
again now that I have the APRS beacon online.

73
Dave
KB3EFS