Difference between revisions of "Realtime process management"
(Initial entry, not complete, also deals mainly with software you can get from testing only!)
|Line 1:||Line 1:|
Revision as of 06:18, 15 September 2005
Realtime for Joe Sixpack
While most processors are powerful enough to play a dozen video or at least audio streams at once, it is possible that another thread hijacks your processor for just half a second to complete another task. This results in short interrupts in audio or video streams. It can also happen that your video/audio streams get out of sync. While it is annoying for casual music listener, a content producer, composer or video editor simply can't accept this problem since it interrupts his/her workflow. The pretended simple solution is to make the audio and video processes a higher priority. But as most users know, Joe Sixpack can set a higher nice value to a process, which means that it's priority is lower. Only root can set lower values and start processes at a lower nice value than 0. It makes sense that the average user cannot steal too much power from processes which are necessary just to keep the system running. This is especially important on multiuser machines. Many realtime desires are limited to single user machines, so this aspect of security is not as critical as it seems. By the same time it should be made sure that the user can really control the priorities only and cannot affect other parts of system configuration which are controlled by root only.
Realtime and Realtime is not the same
Realtime is a synonym for the a process which has as much capabilities to run in time without being interrupted by any other process. A couple of thing can make it dropping cycles nevertheless. Maybe the processor is running out of juice or another process with an even higher priority steals too many CPU-cycles. There is a scaling of realtime quality. The main aspect we are dealing with is the soft realtime. If a box runs out of power and the video editors playback starts to drop frames, the process must be made different like rendering out the preview file so that it can be played without problems. Hard realtime is usually not "desired" but "needed". An example could be made for car's ABS. This can not be "rendered" and there is no second chance.
A Small History to Understand The Problem
There have always been efforts to make it easier for the user to achieve realtime capabilities from the kernel. A lot of patches were floating around the web. As of generation 2.6 there was an addon module available called realtime-lsm. It required CAPABILITY build as module and was only to handle by the more experienced user since the absence of CAPABILITY in the kernel in case that neither capability nor realtime-lsm was loaded can cause trouble.  As of kernel-2.6.12, the so called rlimits patch has been accepted in the mainstream kernel and is now the desired way to provide normal users with realtime capabilities.
Power is Nothing without Control
The realtime-lsm module granted the right to get higher capabilities to users belonging to a certain UID. The rlimit way works similar, but it can be controlled graduated finer. There is a new functionality in PAM which can be used to control the capbilities on a per user or a per group level. In the current version (0.80-2) these values are not set correctly out of the box and still create problems. With PAM you can grant realtime priority to a certain user or to a certain usergroup. PAM#s concept makes it imaginable that there will be ways in the future to grant rights on a per application level. But this is not now possible.
The necessary settings for realtime
First of all, make sure your kernel is compiled with "preemptible kernel" settings. As /boot/kconfig26 tells you, the standard ArchLinux kernel is configured that way. This warning just goes out o all the selfcompilers. Secondly, you need a PAM>0.80 or 0.79-3(that was patched). The last I can confirm working was 0.80-2 from "testing". Just note that the names for the variables in limits.conf have changed from 0.79 to 0.80! Now edit your /etc/security/limits.conf. ArchLinux comes with sane standards for users from the %audio group. Make sure that you are a member of it and you are mainly done. The standard settings are enough to get jack-server running with hydrogen or ardour. For some other applications it might be necessary to redefine the values for rt_prio from 65 to 80 or even higher!
The following settings work for me also with ardour:
@audio - rtprio 70 @audio - nice -10 @audio - memlock 250000