[mythtv-users] Will moving to DDR-400 memory from DDR-333 improve performance?

[Leighton Brough]

Yeechang Lee wrote:
> I currently have 1.5GB of DDR-333 memory in my 3.0GHz,
> Hyperthreading-enabled, Pentium 4-based, dedicated frontend/backend
> with recordings on a NAS. I don't use XvMC to get 1080p output from a
> Nvidia 6200TC card. I record and watch HD streams almost
> exclusively. I've done my best to not run non-essential daemons.
>
> Despite the processor's fairly-recent vintage, I unsurprisingly find
> that when I push the system's limits--by, say, playing back a HD
> recording while recording from more than one of the three HD stream
> sources the system possesses--I get occasional skips in the playback
> with the dreaded "NVP: prebuffering" messages. When this happens, I
> can see the mythfrontend process momentarily hit 99.9% of the
> processor (or, more accurately, one half of the processor) in top
> (refreshing every 0.5 seconds). Also, regardless of whether anything
> is recording, ever since I started running a single mythtranscode
> process in the background 24/7, I've been unable to reliably use the
> beautiful Bob deinterlacing with HD programs, so I use Linear or
> Kernel instead.
>
>   
My experience is that for the kind of config you have (I have similar 
HW: P4 3.0GHz HT, 6200, HD, 2GB), 1.5GB should be OK, even when you 
stress the box. It's possible that you skips are due to the NAS data 
source - I don't have experience of this config - but I doubt it. This 
is a problem that one way or another has plagued many HD myth users 
(both with and without XvMC), as least from what I see on this list.

In my case, playback is rock solid under any stress I throw at it after 
a cold boot, but starts to skip after I've resumed from suspend-to-ram. 
I'm still tracking the issue down. I'm not using XvMC, and am using 
kernel deinterlacing, real-time threads and RTC timing. I have not set 
any of the other Playback settings. I guess I should have a go with bob 
deinterlacing as the word appears to be that this is the best quality.

The processor usage you're seeing is definitely higher than what I see. 
For me around 30 or 40% is typical for HD playback.

 From memory, the list of things I can remember folks suggesting on this 
topic:

1) Try ALSA vs OSS sound (I find OSS is more tolerant of stresses than 
ALSA). You can choose ALSA by specifying "ALSA:default" for the sound 
device and "default" for the mixer in the general settings. I've read 
that ALSA should use less CPU, but I haven't noticed this myself.

2) Try different video timing methods: OpenGL, usleep, RTC (RTC or 
usleep work best for me). You can turn on OpenGL in the playback 
settings if you've compiled with this option. This always produces 
stuttering video for me. To enable RTC timing, you need to "echo 1024 > 
/proc/sys/dev/rtc/max-user-freq" to allow a sufficiently quick frequency 
to be set by the frontend. usleep is the fall-back if neither of these 
are configured. I've read this uses more CPU, but I haven't seen this 
myself. The frontend log shows you what's in use with "Video timing 
method: XXX".

3) Try turning on the extra sound buffering in the playback settings. 
For me this means I get "buffer underrun" messages, rather than 
"prebuffering" messages and more jerky video rather than more stuttery 
audio, i.e. it just moves the problem around.

4) Enable real-time threads in the playback settings. For this, you need 
to have a sufficiently up-to-date PAM library, and put appropriate 
settings in /etc/security/limits.conf. The details are in the myth 
installation doco. When real-time threads are enabled, you'll see "Using 
realtime priority" in the frontend log. I think enabling this can only 
be a good thing, if you want the frontend to tolerate stress.

5) Try fiddling with the other various playback settings. I find I get 
the best results leaving them off.

6) Try the agressive soundcard buffering option in the general settings. 
This hasn't helped me.

7) Try "renice"-ing the frontend or X process. This hasn't helped me either.

8) Try changing the PCI latency of various devices. There's info on the 
wiki and this list about this. It seems with my motherboard, I can't 
change this, so I've been unable to experiment with this. It seems to 
have made a difference for a few users.

9) Make sure your hdparm settings are sane (doesn't really apply to your 
NAS). At least 32-bit IO support (-c 1) and some setting for "multcount" 
(e.g. -m 16) is good or the disk is throttled.

10) Turn off the Sync to VBlank setting for the video texture adaptor in 
nvidia-settings. This works a treat for me, BUT means the video tears 
which is really hard to take once your eye is tuned to notice this.

11) Try different versions of the NVidia drivers. My experience is that 
there were some versions that were dodgy somewhere between 7676 and 
8774. But 8774 and now 8776 seem to work fine. Also the later versions 
have improve support for suspend-to-ram, which is a must for me.

An a suggestion of my own:

12) Try different clocksources. The newer kernels have been 
significantly reworked in this regard and there are differences for the 
SMP kernels (as we are both using). "cat 
/sys/devices/system/clocksource/clocksource0/available_clocksources" 
will tell you what you can use. "echo XXX > .../current_clocksource" can 
be used to set it. Mine defaults to tsc, which is a hardware timer. I am 
definitely getting warm here in finding the solution to my problems 
after resume from suspend-to-ram. It seems the HW timer sources aren't 
correctly re-initialised on resume, so the frontend works about twice as 
hard as it should building video frames (CPU usage doubles to more like 
60 or 70%). When I pick another source like "jiffies" (which I think is 
a software source and is far from accurate) and restart the rtc module, 
playback looks pretty good and CPU usage drops back to the usual 30-40%. 
But I'm in the first few hours of experimenting with this, and various 
video timing methods to try to get the best results.

There may be other suggestions I've forgotten.

Finally, I have to say I did not have this problem with 0.19, but I 
upgraded the kernel at the same time, so that doesn't prove much. I am 
interested to note that lots of folks pointed out higher CPU usage for 
HD playback after the upgrade to 0.20. Also many folks who post about HD 
playback issues point out that on their HW playback with xine or mplayer 
is fine. So there does seem to be some improvements that can be made to 
myth here, if we can work out the issues involved.

I would love to hear from folks who've nailed the problem of HD 
playback, and what did the trick. I know there's a tendency not to post 
to the list once a problem is solved, but I get the impression that 
there's lots of folks who're still fighting with this issue, one way or 
another.

Leighton