[mythtv-users] Prebuffering pauses and CFS

[Michael T. Dean]

No, this has nothing to do with CIFS, the network filesystem.

Recently, I upgraded my MythTV frontend system from an Athlon X2 4800+ 
to an Athlon X2 6000+.  I had always been able to use my old system to 
play back HDTV without any problems--even allowing timestretch.

So, when I set up my new system and was unable to play back HDTV at 
anything >1.0x without severe prebuffering pauses (and using the same 
OS/Myth install), I knew I had an issue.  After testing for the usual 
hardware-related issues (sound card/sound drivers/sound config, 
NIC/network performance), I ruled out hardware as the cause.

Finally, after way too much digging around, I figured out that the Linux 
process scheduler was causing the issues.  When upgrading the hardware, 
I switched to a mobo that had a chipset that wasn't supported by my old 
kernel, so I built a new kernel.  In the process, I enabled the 
Completely Fair Scheduler (CFS, a process scheduler) and Completely Fair 
Queuing (CFQ, an I/O scheduler).  It turns out that the CFS 
configuration was broken and my BOINC/SETI at home (running at nice 19) was 
causing the problems (and would have caused even more problems--probably 
preventing 1x playback--on lower-powered systems).

When I enabled CFS, I chose to enable GROUP_SCHED ("Group CPU 
scheduler", "This feature lets CPU scheduler recognize task groups and 
control CPU bandwidth allocation to such task groups.") and chose 
USER_SCHED as the value for "Basis for grouping tasks", where USER_SCHED 
means, "This option will choose userid as the basis for grouping tasks, 
thus providing equal CPU bandwidth to each user."  Since my mythfrontend 
was running as the mythtv user and my boinc was running as a different 
user, the scheduler was ensuring that boinc got its fair share of CPU 
time--exactly what I had tried to prevent with nice/ionice'ing the 
process.  The only way to work around this issue with USER_SCHED is to 
ensure both processes--mythfrontend and boinc--ran as the same user 
(such that the relative nice values were the determining factor for 
priority).

Instead, I chose to change the kernel configuration (which requires a 
kernel recompile) to use "CGROUP_SCHED", which means "This option allows 
you to create arbitrary task groups using the 'cgroup' pseudo filesystem 
and control the cpu bandwidth allocated to each such task group. Refer 
to Documentation/cgroups.txt for more information on 'cgroup' pseudo 
filesystem."  With this configuration, all processes start in the same 
default cgroup, meaning--without any explicit configuration--the nice 
value is the determining factor for prioritization.  A better 
configuration is to actually create a control group, i.e. "background" 
with a /very/ low cpu.share (i.e. since cpu.share is a relative priority 
mechanism, specific values are irrelevant, and since the default 
cpu.share is 1024, setting processes in the background cgroup to 2 
definitely ensures they don't cause problems :).  This approach provides 
unlimited control over CPU prioritization--you could even create 
multimedia or database or ... cgroups and give them higher priority than 
even the default cgroup (so they would get higher priority than 
services, like SSH, etc.).

The main reason I'm mentioning this in its own thread is that there have 
been a /lot/ of threads on prebuffering pauses "with plenty of CPU" that 
may be due to this misconfiguration.  From digging through the 'net for 
information, it looks like a large number of distros are shipping 
kernels configured to use GROUP_SCHED with USER_SCHED, so if you're 
running processes--especially CPU-hungry processes, like MySQL or 
BOINC--on your frontend systems as different users, you may need to fix 
things.***

Mike

***"Fixing things" (and figuring out how best to "fix things") is left 
as an exercise for the reader.  :)