[mythtv-users] Mythfrontend idle cpu consumption help

[Michael T. Dean]

On 11/17/2009 03:12 AM, markgarland wrote:
> Re: 15% CPU usage in idle mythfrontend.
>   
>> This, I would say, is all just normal operation
>> I.e. you guys don't have an issue so much as have a "feature request." :) 
>>     
> I really couldn't disagree more.  If an application server at work used 15%
> at idle it would be investigated.
>   

You cut out the part that basically said it was just an incomplete 
implementation, but that the current implementation gives the behavior 
of "15% CPU usage" and a planned improvement will show benefits.

(By the way, "15% CPU usage" on its own is useless information.  It's 
like saying, "My recordings take up 15% of my drive space.  Is this 
normal?"  Without knowing how large the drive is, it's impossible to say 
whether that's normal.)

>> Basically, there are way too many people grouping many different
>> symptoms together as "Mythfrontend idle CPU consumption" issues. 
>>     
> I know that the waters are quite muddy as the thread is confusing, however
> to my knowledge there are at least 5 people that are experiencing 10-15%
> CPU usage when the frontend isn't doing anything.  This also seems to be
> appearing over multiple platforms (some with Ubuntu/Debian, some with
> others, some with glibc others with eglibc).
> Forgetting for a moment, any mention of timestamps, NFS shares, or runaway
> processes - the mythfrontend process in its raw state (in my case, out of
> the Ubuntu repositories) seems to idle intermittently at 15% CPU.  This is
> *not* normal operation for an application, IMO, and there is definitely a
> bug here.  I am just struggling with my limited skills to understand
> whether it is a mythtv bug, a library bug, or a kernel bug, although
> Jansen's polling idea sounds interesting.
>   

Again, that's completely normal for the /current/ implementation of the 
UI with some themes.  There /is/ a ticket ( 
http://svn.mythtv.org/trac/ticket/7525 ) already filed that shows "it 
[will] be investigated" (or, more to the point--the design will be 
changed to make it more efficient, as this is an already-understood 
feature of the current design).

As I said, it's a "feature request."  Because Myth has /never/ had an 
efficient implementation of alpha pulse handling (see below), it will be 
a new feature when the work for #7525 is completed.  (This isn't to say 
that the feature won't be backported--only to say that it /will/ be 
new.)  That doesn't mean it's not normal for the current 
implementation.  That doesn't mean it's a bug.

But, basically, we're all stuck with it until someone implements the 
new, more-optimized design being planned in #7525.

> Can I ask what platforms you are using and whether you experience *this
> exact issue*?
>   

glibc-based and I get 10-15% CPU usage (of an Athlon X2 5000+) on some 
themes when idling in some areas (such as Watch Recordings) on my 
0.22-fixes and my trunk installs.

Note, also, that I get 5-10% CPU usage (of an Athlon X2 6000+) on some 
themes when idling in some areas (such as the Menu in G.A.N.T) on my 
/0.21/-fixes install (no, that's not a typo--I mean 0.21-fixes, the 
version of MythTV that preceded the current release).  And, G.A.N.T made 
/much/ less use of alpha pulse than do some of the new themes.  Note 
that on the same setup, using a theme without alpha pulse, I see 0-1% 
CPU usage at idle.

Again, the /only/ issue that I think is a real bug (as opposed to a 
not-complete design) is the 100% CPU usage that some are seeing.  I'm 
now leaning toward NFS being the culprit (and the broken kernel(s) with 
broken NFS caching)--but then again, I've lost track of which users who 
are seeing that 100% CPU usage bug have what configurations because of 
all the other noise on what I'm pretty sure is just plain normal.

Disable alpha pulse in the theme you're using and I'll bet your CPU 
usage drops noticeably...  (Or, install 0.21-fixes and load up G.A.N.T 
or add some alpha pulse to some other themes and I'll bet you'll see the 
CPU usage isn't low for the previous version, either.)

Mike