Mailing List Archive

At 04:09 PM 5/22/2003 -0500, Hellboy wrote:
>I noticed when I was running MythTV, and watching Live TV that my CPU
>utilization was through the roof. My Athlon 900 was running between 88% and
>94.8% and leaving me with about 8MB of RAM left out of 384MB. Needless to
>say, that the box crashes for what I'm assuming is too heavy of a workload.

This description contains several (probable) misunderstandings.

1. You do understand, I hope, that "live TV" is not really "live". It is
buffered, so the system has to run both an encoding process (mythbackend
does that) and a decoding process (mythfrontent does that). So high CPU use
is normal in this setting, especially for a relatively low-power system
like yours.

2. The Linux kernel handles memory use in wuch a way that after a system
has run for awhile, it will always report near-100% RAM use (I mean here
the simple report that "top" provide, not the better one that "free"
provides).

3. Even under heavy loads like this, systems do not normally "Crash", so
there is no "needless to say" about it. See below for more on this one.

>I used SSH to log in remotely, and noticed that there were between 4 and 6
>processes for mythbackend that were running. Also, there were 2 or 3
>instances of mythfrontend running as well, each taking up 33MB of RAM. The
>number would fluctuate (one minute there would be two processes, the next
>would be six, then back again).

Both mythfrontend and mythbackend are threaded apps, and threads show up as
multiple "processes" in top and ps. While what you are *seeing* could be
indicative of a problem, what you are *describing* is way too vague to
distinguish what you are seeing from normal operation.

>According to the docs, an 800MHZ P3 should be able to encode and decode
>allowing for Live TV watching (although I'm assuming not much else).

Do the docs really say this? Without qualification? Your use of RTJPEG
halps lighten the load, but even so, I'd be surprised if this system, or
yours, can handle the load at the standard (480x480) capture size. My Cel
1.7 GHz, running MPEG4, can just barely do it.

>I
>realize my CPU specs are not much higher than the bare minimum, and my RAM
>is lower than the 512MB but it looks like it should be able to pull it off.
>I'm using RTJPEG at the default cap res also.
>What concerns me is the multiple instances of both programs running, and I'm
>wondering if this normal, or if it is something I could pare back on. Sorry
>if this is kind of a noob question, but, well, I'm kind of a noob at this.
>Thanks for the help.

Aside from the crashes, are you seeing any of the usual problems that
people describe in messages here when a MythTV system cannot keep up with
the load?

If the crashes are the only problem, I'd look elsewhere than Myth itself
for starters ... a bad component (mobo, CPU, RAM), a miscompiled kernel
(trying to run DMA on a drive without including kernel support for the
mobo's IDE chipset), overheating. It's hard to be specific without a better
description of the symptom than "crashes" ... does the system freeze up and
require a power-cycle reboot? Is there a kernel oops? Or what? After the
system has "crashed", does it respond to pings? What else can you tell us
about the crashes?

Your machine should probably not crash. I use linux in a variety of
situations including where the CPU is pegged out for long stretches.
This is the situation when you play any modern 3d game (or most games
really.) If your machine is crashing, you should probably look into why
that is first! See if you can crash it without using mythtv...

Linux generally uses all available RAM, all the time. Any RAM not used
by processes gets used for cache. It's normal to have very little RAM
free at any one time.

The size of the processes can be very misleading as well. For one, the
RSS (resident) size of the process is what's actually in memory. Also,
you might notice that there are a large number of shared pages as well.
This means that those pages of memory are also used by another program,
quite likely other instances of the same program but I believe it
includes shared libraries as well.

I wouldn't worry so much about seeing multiple processes, perhaps
someone more knowledgeable about the code could comment on that.

What happens with LiveTV (or playing back a recording which is not
finished) is that all the AV data goes over a tcp socket instead of
mythfrontend reading directly from the unfinished file. This actually
takes a healthy amount of CPU time for mythbackend to handle (it seems
to me like too much, but what do I know.) My 1400 MHz athlon was in the
same boat... I could record 2 shows, and playback a previously recorded
show but if I tried playing a show still recording (while recording
another) or using livetv (again while recording another) I would get
very choppy playback.

In any case, it seems like you're system is simply borderline fast
enough and you should either up your hardware or look into making sure
everything is set up correctly.

DMA enabled on all hard drives (and probably CD-ROMS too)?
Xvideo extensions work for your card?
Try seeing if IRQ's are shared for critical devices (like the capture
card and your video card) and if they are split them up.

All of the above and many other things may make the difference in
getting your system running smoothly.

Hope that helps...

PS: Almost everything I've said here has been said more clearly before
on this list... the archives are your friend.



On Thu, 2003-05-22 at 16:09, Hellboy wrote:
> I noticed when I was running MythTV, and watching Live TV that my CPU
> utilization was through the roof. My Athlon 900 was running between 88% and
> 94.8% and leaving me with about 8MB of RAM left out of 384MB. Needless to
> say, that the box crashes for what I'm assuming is too heavy of a workload.
> I used SSH to log in remotely, and noticed that there were between 4 and 6
> processes for mythbackend that were running. Also, there were 2 or 3
> instances of mythfrontend running as well, each taking up 33MB of RAM. The
> number would fluctuate (one minute there would be two processes, the next
> would be six, then back again).
> According to the docs, an 800MHZ P3 should be able to encode and decode
> allowing for Live TV watching (although I'm assuming not much else). I
> realize my CPU specs are not much higher than the bare minimum, and my RAM
> is lower than the 512MB but it looks like it should be able to pull it off.
> I'm using RTJPEG at the default cap res also.
> What concerns me is the multiple instances of both programs running, and I'm
> wondering if this normal, or if it is something I could pare back on. Sorry
> if this is kind of a noob question, but, well, I'm kind of a noob at this.
> Thanks for the help.
>
> Wes
>
> P.S. Down with SCO!!
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

I do understand that live tv is not live. This was explained in the docs
regarding audio issues while listening to a "live stream" vs. the playback
after it is decoded. I was not aware of what processes were responsible for
what though. Thanks for the information. Tonight, I will try free to get a
more accurate representation of RAM usage.

This was what I was refering to in the documentation regarding CPU usage:
"A PIII/800Mhz system with 512MB RAM can encode one video stream using the
RTJPEG codec with 480x480 capture resolution and play it back
simultaneously, thereby allowing live TV watching." This is what I was
basing my assumption off of.

As for a more accurate description of the "crash", here it is. Actually, one
of two things takes place:
1. The systems locks up completely, and will not respond to anything. I
cannot ping it, the escape sequence (I have Alt-Esc to shut down MythTV)
doesn't work. Nothing. I have to do a hard reset to bring it back.
2. The system reboots itself during playback. I usually get about 5 minutes
before shutdown (long enough to get my hopes up that it will actually work).
I am running mythbackend with the -l arguement hoping to catch a glimpse of
what's going on, but when I reboot, the file is missing. This perhaps is
something that I'm doing wrong?

Another reply mentioned running other resource intensive apps such as games
on Linux and having that eat a lot of resources. This is actually the
previous incarnation of this server. I ran UT2003, MOHAA, and Battlefield
1942 on this machine before (not all at once), all with 16 players and it
held up well. While I realize that this is apples to oranges, I felt the
good performance under high CPU workloads made this machine a good candidate
for MythTV.

In the docs, it stated that more often than not, audio can be the problem.
"Audio appears to be one of the bigger issues that users run into on the
mailing list. If the audio isn't configured correctly, then MythTV will
often appear to hang, when in fact it is trying to manipulate the audio
subsystem and failing. You may or may not receive error messages indicating
that the source of the error is the audio subsystem." I am using the alsa
via82xx drivers (I believe it is RC8). The troubleshooting steps all work
out fine for me. hdparm -d on hda and hdc all show as on.

I will try to switch up some of the hardware tonight to see if it maybe is a
driver issue. I am using a PC PVR card from IOMEGA. It has a Pinnacle tuner
and a bt878 chipset, so i thought it would be fine. I'll try the Hauppauge
WinTV Go instead. Hope this was the info you needed me to provide. Thanks to
all for the help.

Wes


-----Original Message-----
From: mythtv-users-bounces@snowman.net
[mailto:mythtv-users-bounces@snowman.net]On Behalf Of Ray Olszewski
Sent: Thursday, May 22, 2003 4:44 PM
To: mythtv-users@snowman.net
Subject: Re: [mythtv-users] mythbackend


At 04:09 PM 5/22/2003 -0500, Hellboy wrote:
>I noticed when I was running MythTV, and watching Live TV that my CPU
>utilization was through the roof. My Athlon 900 was running between 88% and
>94.8% and leaving me with about 8MB of RAM left out of 384MB. Needless to
>say, that the box crashes for what I'm assuming is too heavy of a workload.

This description contains several (probable) misunderstandings.

1. You do understand, I hope, that "live TV" is not really "live". It is
buffered, so the system has to run both an encoding process (mythbackend
does that) and a decoding process (mythfrontent does that). So high CPU use
is normal in this setting, especially for a relatively low-power system
like yours.

2. The Linux kernel handles memory use in wuch a way that after a system
has run for awhile, it will always report near-100% RAM use (I mean here
the simple report that "top" provide, not the better one that "free"
provides).

3. Even under heavy loads like this, systems do not normally "Crash", so
there is no "needless to say" about it. See below for more on this one.

>I used SSH to log in remotely, and noticed that there were between 4 and 6
>processes for mythbackend that were running. Also, there were 2 or 3
>instances of mythfrontend running as well, each taking up 33MB of RAM. The
>number would fluctuate (one minute there would be two processes, the next
>would be six, then back again).

Both mythfrontend and mythbackend are threaded apps, and threads show up as
multiple "processes" in top and ps. While what you are *seeing* could be
indicative of a problem, what you are *describing* is way too vague to
distinguish what you are seeing from normal operation.

>According to the docs, an 800MHZ P3 should be able to encode and decode
>allowing for Live TV watching (although I'm assuming not much else).

Do the docs really say this? Without qualification? Your use of RTJPEG
halps lighten the load, but even so, I'd be surprised if this system, or
yours, can handle the load at the standard (480x480) capture size. My Cel
1.7 GHz, running MPEG4, can just barely do it.

>I
>realize my CPU specs are not much higher than the bare minimum, and my RAM
>is lower than the 512MB but it looks like it should be able to pull it off.
>I'm using RTJPEG at the default cap res also.
>What concerns me is the multiple instances of both programs running, and
I'm
>wondering if this normal, or if it is something I could pare back on. Sorry
>if this is kind of a noob question, but, well, I'm kind of a noob at this.
>Thanks for the help.

Aside from the crashes, are you seeing any of the usual problems that
people describe in messages here when a MythTV system cannot keep up with
the load?

If the crashes are the only problem, I'd look elsewhere than Myth itself
for starters ... a bad component (mobo, CPU, RAM), a miscompiled kernel
(trying to run DMA on a drive without including kernel support for the
mobo's IDE chipset), overheating. It's hard to be specific without a better
description of the symptom than "crashes" ... does the system freeze up and
require a power-cycle reboot? Is there a kernel oops? Or what? After the
system has "crashed", does it respond to pings? What else can you tell us
about the crashes?



_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

At 06:01 PM 5/22/2003 -0500, Hellboy wrote:
>[...]
>As for a more accurate description of the "crash", here it is. Actually, one
>of two things takes place:
>1. The systems locks up completely, and will not respond to anything. I
>cannot ping it, the escape sequence (I have Alt-Esc to shut down MythTV)
>doesn't work. Nothing. I have to do a hard reset to bring it back.
>2. The system reboots itself during playback. I usually get about 5 minutes
>before shutdown (long enough to get my hopes up that it will actually work).

In a different (non-Myth) setting, I had trouble with a machine doing video
capture. The symptoms were varied ... sometimes a kernel OOPs, sometimes
apps started segfaulting, sometimes everything worked fine except for video
capture. I never did solve that one ... just gave up using the machine for
vidcap (it works fine for everything else I've used it for, including
demanding things like kernel compiles and heavy ftp loads). Speculation
here was a problem with the front-side bus, but I couldn't find a way to
test that possibility specifically.

Just a thought ... these symptoms, vague as they are (though I don't see
how you can be more specific, since the X server conceals the console
where an OOPS would be shown) sound like they might be the same sort of thing.

FYI, when my system was locking up "hard" with Myth, I traced it to DMA on
my hard drive. I turned it off and it quit locking up. Bought a new hard
drive and turned DMA back on and problem was gone. Try turning it off with
hdparm -d0 /dev/hda (or whatever) and see if that helps. I've also seen the
suggestion before that you use a "nul" audio device as a troubleshooting
step.

Take care,
JC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> As for a more accurate description of the "crash", here it
> is. Actually, one
> of two things takes place:
> 1. The systems locks up completely, and will not respond to
> anything. I
> cannot ping it, the escape sequence (I have Alt-Esc to shut
> down MythTV)
> doesn't work. Nothing. I have to do a hard reset to bring it back.
> 2. The system reboots itself during playback. I usually get
> about 5 minutes
> before shutdown (long enough to get my hopes up that it will
> actually work).
> I am running mythbackend with the -l arguement hoping to
> catch a glimpse of
> what's going on, but when I reboot, the file is missing. This
> perhaps is
> something that I'm doing wrong?

To me, this sounds like the classic symptoms of a system that's
overheating under load. Do you have lm-sensors running?

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPs4axfc1NpCTlP0JEQIZVwCfQIXylguvILbPpNRElf4IiVx1zIUAnAj1
gM4BjooLe90aDzhp1uQk9qoq
=dXYg
-----END PGP SIGNATURE-----