• 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 22
No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)
#61
Exclamation 
Guys before everyone gets too excited...

I just ran the Killa' Sample on the system here I recently built. This TV does full screen at 1280X720 @50hz so I guess 720P? Vert synch is always on. I know I ran it at higher rez on my panel testing this and didn't see issues then either. Anyway, Killa plays SMOOTH here. Both CPU are EVEN and don't go over 80% through the playback. I see 10 frames dropped on the first playback, set the system for 1080i (saw no difference in apparent rez) and dropped 14 - all at the start.

Even if the rez is making a difference it still has to decode this nasty file. I do not believe that this system is displaying the same quirks that everyone here seems to be seeing. One thing about this system - I never removed PulseAudio maybe that makes a difference? So, before everyone goes digging into kernel internals and freaking out maybe there's some simple difference here? I get MY new board tomorrow, figure a few days before it's installed, and then we'll see what it does on my system - I'll be upgrading to 8.1.

Also, forget trying to play Killa' with an AMD. I have yet to hear of anyone managing it. Forget trying to compare AMD clocks with Intel clocks, the C2D is simply that much better for this app.Shocked
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
Reply
#62
Res makes no difference, it's free to the CPU. This system is running 8.10? If so what are the stats (make and model please).
Reply
#63
Sure, here's the entire build -> http://secure.newegg.com/WishList/Public...er=9999386

I overclocked it to about 3.1ghz. Latest SVN pull as of tonight. I'd give you the exact revision except that it's playing a TV show right now.Laugh

I loaded 8.1, updated the ALSA for HDMI audio, and loaded the Intrepid NVIDIA drivers (closed source). I don't recall doing anything special other than setting an .asoundrc file - no stereo audio though just 5.1 via HDMI.

If you need me to run soem commands to pull more info just lemme' know. Oh, I have the latest BIOS on this board loaded too. I cannot think of anything else pertinent so fire away...
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
Reply
#64
Could be the Nvidia drivers I suppose, alanwww1 swore the hardy worked fine for him, however I installed both hardy and Fedora 10 last night, and both had the exact same issue. (I used 180.18 on all installations)
Reply
#65
i don't think it's a Nvidia issue - i see the issue using intel graphics 2.4.1 (DG45FC MB with e8400, 2GB ram)
Reply
#66
Interesting point. I'm using pulseaudio as my default sound device, and routing it through HDMI also.

Anyone suggest a longer h264 clip that I can test? By the time I get the killa sampla loaded, alt-tab and look at top, it's over!
Reply
#67
mr_raider Wrote:Anyone suggest a longer h264 clip that I can test? By the time I get the killa sampla loaded, alt-tab and look at top, it's over!

You can have the sample start with web interface looking at TOP with ssh connection from another computer. I only have Dark Knight BD-rip, but it is only a max 20Mpbs video stream. The killa goes somewhere 40-50Mpbs.

I think it is not the Nvidia driver the problem i tried 177 and 180.18 with same results. I also ran a test last night with the killa.

With Hardy at 2.5Ghz E7200 there were only a few (max 2-3) dropped frames, but clocking it up to 2.7Ghz all was fine,

but with Intrepid at 3Ghz without Motd2's compile modification i had hundreds of dropped frames,
with Motd2's modification at 3Ghz i still have some 20-30 dropped frames.

So i think even with Motd2 compile modification we have some 20-30% performance difference between Intrepid and Hardy, without the modifications i think it is somewhere 50% or more the difference.
Reply
#68
althekiller Wrote:At least read up on the new linux process scheduler (it's called The Completely Fair Scheduler or CFS). It was enabled by ubuntu in 2.6.26 IIRC.

Sorry but i am pretty new to linux world. I just try my best to help you and the community to test all you or anyone suggest, but i really don't have enough knowledge for Linux kernel in detail.

I think that you are right that this new scheduler should be the difference why we are having such bad performance on Intrepid. At least i think we know where to look for the right solution. Anyway i made some reading and find this page where they specificly write about Intrepid scheduler setting problems. I don't know if it helps or not, but here it is anyway:

https://bugs.launchpad.net/ubuntu/intrep...bug/188226

ps. Devs of XBMC are great i wish i could help you more
Reply
#69
Big Grin 
I would point out, again, that I am NOT seeing this issue so before you decide it's the scheduler you might want to take into account that I am running the SAME scheduler without this issue. If this were the kernel wouldn't I be seeing this tooHuh?
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
Reply
#70
I never said it _was_ the scheduler. But that's the thing that picks when and where other things get executed, so it seems a reasonable place to start. However, I didn't come across any particularly damning info in the docs and IIRC CFS is the only scheduler available as of somewhere in the 2.6.24-26 range. So, there isn't really a whole lot we can do about it even if it was the problem.
Reply
#71
Is there anyone besides myself NOT seeing this issue on IntrepidHuh
Openelec Gotham, MCE remote(s), Intel i3 NUC, DVDs fed from unRAID cataloged by DVD Profiler. HD-DVD encoded with Handbrake to x.264. Yamaha receiver(s)
Reply
#72
Im not sure Im seeing it. I can test on my Core Duo 1.66Ghz I guess. Not sure what clip to test though. I have the killa sample but obviously it is dead slow.
Reply
#73
BLKMGK Wrote:Is there anyone besides myself NOT seeing this issue on IntrepidHuh

You can't be sure if you are seeing it or not, unless you try the SAME hardware with Hardy and Intrepid. You will see night and day diference between them.

If you are using an overclocked CPU to some 3.1 Ghz it might be enough for Intrepid,(on 3ghz mine has some 20-25 fropped frames in the killa sample) but on Hardy a 2.6Ghz E7200 is enough for the killa sample. It is already some 20% performance difference.

An more and more i read about the new scheduler i get the impression that this is the problem. There are tons of threads about various issues with multithreading performance degradation with the new scheduler as it is optimized more on running multiple applications with even resource distribution than to have all the resources to one specific process. There are some parameters which can be tuned with it but it needs more research. I started a thread about this on kerneltrap.com forum.
Reply
#74
Hi,

I'm really interested in this issue as I'm getting an htpc this next week and I'm unsure of what distribution should I use. In any case, alanwww1 could you please post a link to the kerneltrap thread?

Also, are you using the same user to run xbmc and the rest of the gnome/xorg? if it is the scheduler maybe running different groups/users affects it (don't think so but who knows... Smile

Of course, as soon as I get my hardware I'll install a fresh install of both hardy and intrepid to test this problem.

regards,
Reply
#75
Quote:if it is the scheduler maybe running different groups/users affects it (don't think so but who knows...
pulluli - nice point - unfortunately i happened to be running xbmc as root last night to try and get round a different issue with the new intel 2.5.1 drivers (GPU registers as software rastersizer run as user - Mesa DRI as root). I tested to the killa sample and saw same issue. cores uneven ~100%, ~10%with 60+ dropped frames by the end. I also noticed the load alternating between the two. e.g. beginning c1=100% c2=10% --> then load would shift to e.g c1=10% c2=100%. I'd not noticed this before however i remember reading another post about mplayer switching cores like this. - i'll try and dig it out -- actually post by motd2k #29 of this thread - shows the cores switching.

obviously the figures are not the exact ones but the core load is most certainly uneven, and obviously so.

BLKMGK - do you do a clean install from CD or a clean install of hardy then upgrade? I'm interested into why don't possibly see the issue.
Reply
  • 1
  • 3
  • 4
  • 5(current)
  • 6
  • 7
  • 22

Logout Mark Read Team Forum Stats Members Help
No multithreaded Video decoding on XBMC INTREPID version (in-depth testing)1