[mythtv-users] System Load/Performance Question

[Brian Wood]

>
> On Sunday 19 February 2006 17:20, Brian Wood wrote:
>> I know the "can this system do <blank> has been done to death here,
>> but I need some comparisons.
>>
>> The system is an amd64 3700, running Gentoo 2.6.15, MythTV
>> 0.18.1,1.5GB RAM
>>
>> We are talking strictly about SDTV here.
>> 2-PVR-150s
>> GeForce-5700 video card w/256MB.
>> nVidia 7676 drivers, no XvMC, MythTV compiled with OpenGL support
>>
>> Recordings are going onto 2-250GB SATA drives configured Linux kernel
>> software RAID0, JFS filesystem.
>> Ring Buffer is going onto a UDMA 133 250GB single drive, JFS
>> filesystem, no other drive on the IDE channel, The OS is on another
>> partition of this drive.
>>
>> If I have a recording happening on tuner 1, and am watching LiveTV
>> from tuner 2, and have a commercial flagging job happening, I get
>> digital breakup on the live picture, and occasional breakup in the
>> recording.
>>
>> Without a flagging job running there is no breakup on liveTV or the
>> recording.
>>
>> CPU usage shows about 30-35%, no swapping is happening.
>> The priority of the flagging job in MythSetup is set to "low".
>> vmstat shows "WA" as "1", and very occasionally "2"
>>
>> So, my questions:
>>
>> Is this normal, am I simply asking too much of the system?
>> Is it a disk IO problem? (I don't think it's a CPU problem)
>> Would putting the ringbuffer on the RAID system help?
>> Would moving to a SCSI disk system help?
>> Should I just run flagging jobs at other times?
>> Is having the ringbuffer on the same drive as the OS a bad idea?
>>
>> Obviously I'd like to figure out what the weak link is in this system
>> that is causing the breakup, any ideas appreciated.
>>


On Feb 19, 2006, at 9:15 PM, Jonathan Lin wrote:
> what is your system load avg?  also check your interrupt.  I have  
> an AMD 64
> box here running gentoo 2.6.15-R5 with 3 different tunners and I only
> encounter problem when the mythcomflag is running against my HD  
> recordings.
> (my system load avg shoots up to 7).  Now I enable XvMC and I no  
> longer have
> skippings, but then my situation is with HD and not SDTV.

That's what's weird, load averages 0.24,0.16,0.16, nothing that  
should be a problem. I'm not sure what you mean by check interrupts,  
but cat /proc/interrupts shows:

0:   53499793    IO-APIC-edge  timer
   1:       3578    IO-APIC-edge  i8042
   8:          0    IO-APIC-edge  rtc
   9:          0   IO-APIC-level  acpi
12:       1806    IO-APIC-edge  i8042
14:     488079    IO-APIC-edge  ide0
15:    3772562    IO-APIC-edge  ide1
169:    1136388   IO-APIC-level  eth0
177:     122028   IO-APIC-level  libata
185:     396243   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2,  
uhci_hcd:usb3, uhci_hcd:usb4, uhci_hcd:usb5
193:    1009584   IO-APIC-level  VIA8237
201:    1230285   IO-APIC-level  ivtv0
209:     289743   IO-APIC-level  ivtv1
217:          0   IO-APIC-level  cx88[0], cx88[0]
225:   30000476   IO-APIC-level  nvidia
NMI:      10686

I don't see any problems there (the cx88 card is not set up in  
MythTV), the only sharing I see is USB, which I'm not using.

I just set up the offending situation again to get these numbers and  
I'm again getting the digital breakup, and occasional audio hits.  
vmstat shows 97 % idle and 0 wa. Mythfrontend shows between 12 and 15  
% CPU

Top shows:

20457 root      15   0  347m 136m  38m S 12.0  9.1   0:02.79  
mythfrontend
10226 root      15   0  349m  72m  18m S  3.7  4.8  15:35.91 X
20402 root      32  17  147m  39m  14m S  3.0  2.7   0:17.77  
mythcommflag
20460 root      -2 -19  347m 136m  38m S  0.7  9.1   0:00.17  
mythfrontend
20413 root      32  17  147m  39m  14m R  0.3  2.7   0:00.21  
mythcommflag
20444 root      16   0 10556 1316  928 S  0.3  0.1   0:00.44 top


I'm running 2.6.15-R1 (not sure what changed with R5). Mythcommflag  
shows a niceness level of 17, so it really shouldn't be bothering  
anything.

I think I'm missing something significant here, but I haven't the  
faintest notion what it might be.

Thanks for the data point.