Realtime process management

From ArchWiki
Revision as of 22:52, 19 December 2009 by Jasonwryan (talk | contribs) (Complete edit of the intro for clarity)
Jump to navigation Jump to search

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Reason: please use the first argument of the template to provide a brief explanation. (Discuss in Talk:Realtime process management#)

Realtime for Normal users

While many recent processors are powerful enough to play a dozen video or audio streams simultaneously, it is still possible that another thread hijacks the processor for half a second to complete another task. This results in short interrupts in audio or video streams. It is also possible that video/audio streams get out of sync. While this is annoying for a casual music listener; for a content producer, composer or video editor this issue is much more serious as it interrupts their workflow.

The simple solution is to give the audio and video processes a higher priority. However, while normal users can set a higher nice value to a process, which means that its priority is lower, only root can set lower values and start processes at a lower nice value than 0. This protects the normal user from underpowering processes which are essential to the system. This is especially important on multiuser machines.

Realtime and Realtime is not the same

Realtime is a synonym for a process which has as much capabilities to run in time without being interrupted by any other process. A couple of things can make it drop 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 editor's 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. [1] 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 capabilities 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 user group. 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 yet 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 Arch Linux kernel is configured that way. This warning just goes out to 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. Arch Linux 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          -       memlock         250000

PAM-enabled Login

See: Start X at Boot

To activate the settings in /etc/security/limits.conf you have to use a PAM-enabled login method/manager. Nearly all graphical login managers are pam-enabled. You can check that by looking for the related line/file in /etc/pam.d:

~$ grep /etc/pam.d/*

If you get nothing, you are whacked. But you will, as long as you have a login manager (and now policykit). The line we are looking for is:

session           required


See: Automatic VC Login

If you prefer to not have a graphical login, you still have a way. You need to edit the pam stuff for su (from coreutils):

# /etc/pam.d/su
session              required

Source (thanks to jochen and dunc):



See: Pro Audio