Es ist schon verteufelt: Trotz Gigahertz und Gigabytes ruckelt das Bild beim Fernsehen am Computer wie eh und je. Woran das liegt und was experimentierfreudige User dagegen unternehmen, erfahren Sie hier.

Linux ist einfach zu gerecht. Als klassisches Multiuser-System war es lange Zeit Windows überlegen, weil auch die Anwendungen mehrerer Nutzer gleichberechtigt ihre Arbeit taten. Heute sitzt vor einem Linux-Computer oft nur ein einzelner Mensch und möchte die ganze Rechenleistung für sich haben. Da fällt es schwer, zu akzeptieren, dass die Sound-Wiedergabe oder das Videobild aussetzen, nur weil im Hintergrund ein paar Systemprozesse laufen und sich vordrängeln.

So gut es geht

Moderne Linux-Kernel bieten an, einzelnen Anwendungen höhere Prioritäten zuzuweisen, sodass sie bei der Zuteilung von Rechenzeit bevorzugt werden. Die ist letztlich begrenzt, und so ist das Ergebnis solchen Tunings stark von der tatsächlichen Auslastung abhängig. So genannte Echtzeit-Priorität ist also hier zu verstehen als “so gut wie möglich”. Für viele Multimedia-Anwendungen bringen die hier beschriebenen Methoden jedenfalls unter normalen Umständen eine deutliche Beschleunigung bzw. größere Stabilität.

Die Lösungen variieren in ihren Ergebnissen wie im erforderlichen Aufwand. Wer die neueste Version seiner Distribution verwendet, wird viele Features schon im Standard-Kernel finden, so etwa ab Kernel-Version 2.6.14 (Rlimits). Der Kernel-Patch von Con Kolivas [1] ist mächtiger, erfordert aber die Übersetzung der gepatchten Kernel-Sourcen. Hinweise dazu gibt der Artikel [2].

In jedem Fall empfiehlt es sich, beim Kompilieren eines Kernels die so genannte Kernel-Preemption einzuschalten. Ob Ihr Distributor dieses Feature einkompiliert hat, erfahren Sie durch einen Blick in die Config-Datei des Kernels, die sie meist im Verzeichnis /boot/grub finden, zum Beispiel bei Ubuntu config-2.6.12-9-k7. Mit Grep suchen Sie dort nach dem String PREEMPT. Stoßen Sie dabei auf CONFIG_PREEMPT is not set oder PREEMPT_NONE, kompilieren Sie den Kernel besser mit geänderten Einstellungen neu (Abbildung 1). Akzeptabel ist dagegen CONFIG_PREEMPT_VOLUNTARY=y, am besten PREEMPT.

Abbildung 1: Wer ein reaktionsschnelles System möchte, sollte beim Kernel-Compile die Option “CONFIG_PREEMPT” einschalten.

Stellt der Kernel Echtzeitprioritäten zur Verfügung, bleibt noch die Frage, wie man sie einschaltet. Normalerweise darf nur Root ein Programm mit Echtzeit-Priorität laufen lassen. Schließlich soll nicht jeder Anwender mit seiner Software den Rechner zum Stillstand bringen können. Der selbst verantwortliche Desktop-User muss aber erst wieder sein Linux-System einstellen, um auch ohne Root-Rechte seine Programme zu beschleunigen.

Echtzeit ohne Root.

Die Community ambitionierter Audionutzer hat schon vor längerer Zeit eine Lösung für die Echtzeitanforderungen des Audioservers Jack [3] gefunden: das Kernel-Modul Realtime-lsm [4]. Die Kernelentwickler haben bislang wegen verschiedener Bedenken das Modul nicht in den Standard-Kernel aufgenommen, es hat sich in der Audio-Praxis aber gut bewährt. Der Zweck des Moduls besteht darin, nicht mit Root-Rechten laufenden Programmen Echtzeitpriorität zuzuweisen. Das ist zum Beispiel bei Jack wichtig, da er mit der gleichen User-ID laufen muss wie die auf ihn zugreifenden Audio-Programme – jeden Synthesizer als Root zu starten, empfiehlt sich aber nicht unbedingt.

Realtime-LSM

Ubuntu führt realtime-lsm im Repository, Benutzer anderer Distributionen laden den Quellcode am besten von der Website herunter. Um Realtime-lsm zu verwenden, muss das Capabilities-Merkmal als Modul vorliegen, also nicht fest im Kernel einkompiliert sein. Das ist zum Beispiel bei Suse 9.3 der Fall, bei Fedora Core 4 nicht. Fedora-Benutzer müssen also den Kernel neu kompilieren und dabei Capabilities als Modul einstellen (Abbildung 2), die anderen brauchen je nach Distribution entweder die Kernel-Sourcen oder zumindest -Header.

Abbildung 2: Um Realtime-lsm zu benutzen, muss Capabilities als Modul kompiliert sein.

Wenn die Voraussetzungen erfüllt sind, übersetzen und installieren Sie Realtime-LSM mit make und make install. Wenn Sie dann noch depmod -a ausführen, können Sie mit modprobe realtime-lsm das Modul laden. Es versteht einige Parameter, die sein Verhalten festlegen. So vergibt es mit any=1 Echtzeitpriorität an jedes Programm, das diese anfordert. Etwas mehr Kontrolle erlaubt der Parameter gid, der die Gruppen-ID autorisierter Programme festlegt. Gehören Sie zum Beispiel der Gruppe audio mit der ID 33 an, laden Sie das Kernel-Modul mit modprobe realtime-lsm gid=33. Nun können Sie auch ohne Root-Rechte Jackd mit der Option -R im Echtzeitmodus starten.

Rlimits

Statt der beschriebenen Lösung ziehen die meisten Kernel-Entwickler die Vergabe der Realtime-Priorität über den Rlimit-Mechanismus vor, der deshalb seit Version 2.6.14 Teil des Standard-Kernels ist. Das R in Rlimits steht allerdings nicht für Realtime, sondern für Ressource. Es erlaubt die Nutzung verschiedener Systemressourcen festzulegen, wie beispielsweise den Speicherverbrauch oder eben die Priorität.

Der von den Entwicklern vorgesehene Weg zur Steuerung von Rlimits führt über das PAM-Subsystem (Pluggable Authentication Module), das sich auf vielen Distributionen (Fedora, Suse, …) unter anderem um die Passwortverwaltung kümmert. Dummerweise beherrschen nur neue (ab 0.79) und gepatchte PAM-Versionen die Rlimits. Haben Sie eine solche installiert, stellen Sie in der Datei /etc/security/limits.conf ein, welche Anwender bzw. Gruppen Echtzeitprioritäten zuweisen dürfen. An erster Stelle steht die berechtigte Gruppe, dann die Ressource und der Wert. Die zweite Spalte legt normalerweise fest, ob der Benutzer den vorgegebenen Wert verändern darf (soft) oder nicht (hard). Ressourcen sind zum Beispiel die Realtime-Priorität rt_priority, der Nice-Level nice und die Menge zu sperrenden Speichers memlock.

@audio hard rt_priority 80
@audio hard nice -10

Wer nicht das komplette PAM seiner Distribution aktualisieren möchte, kann auf ein spezielles Utility zurückgreifen, das sich nur um die Echtzeitpriorität kümmert und entsprechend set_rtlimits heißt [5]. Damit nicht jeder nach Lust und Laune priorisiert, legt der Administrator über die Konfigurationsdatei /etc/set_rtlimits.conf fest, welche Benutzer oder Gruppen das dürfen. Zusätzlich führt die Datei die Programme selbst auf, die Echtzeitpriorität erhalten können. Folgende Zeile erlaubt das dem Benutzer joey für den Jack-Server /usr/bin/jackd:

joey /usr/bin/jackd -1 80

Die erste folgende Zahl gibt den maximalen Nice-Wert an (siehe die Manpage zu nice), die zweite die maximale Echtzeitpriorität. Eine negative Zahl legt fest, dass der Benutzer den entsprechenden Wert nicht verändern darf. Berechtigte Benutzergruppen erkennt das Programm an einem führenden @-Zeichen, also zum Beispiel @audio. Sie starten dann das gewünschte Programm mit volem Pfad über das Kommandozeilen-Tool:

set_rlimits -r=80 /usr/bin/?
mythfrontend

Da Rlimits nun Teil des Standard-Kernels ist, werden schon die nächsten Versionen der Distributionen es unterstützen. Hoffentlich gibt es dann auch bequemere Tools, die den Benutzer auf einfache Weise Anwendungen priorisieren lassen.

Con Kolivas’ Patchset

Vor einiger Zeit sorgte der australische Zahnarzt Con Kolivas auf der Linux-Kernel-Mailingliste für Aufregung, als er sich in kurzer Zeit erst C-, dann Kernel-Programmierung beibrachte und schließlich kurzerhand den Scheduler des Kernels verbesserte. Diese Komponente teilt den laufenden Programmen reihum regelmäßig Rechenzeit des Prozessors zu. Je weniger Zeit er dazu braucht, desto schneller laufen die Programme scheinbar gleichzeitig. Der Scheduler von Con Kolivas ist mittlerweile Teil des Standard-Kernels, einige andere Performance steigernde Patches bietet er auf seiner Homepage an.

Das Patchset bringt unter anderem einige neue Prioritätsklassen für Echtzeit mit, zum Beispiel SCHED_ISO und SCHED_BATCH. Die Batch-Priorität eignet sich vor allem für lang laufende Prozesse auf Server-Rechnern. Bei dieser Klasse lässt Server-Programm etwas länger arbeiten , bis der Scheduler sie unterbricht. Das sorgt für weniger Reibungsverluste beim Umschalten. Im Gegenzug kann das Linux-System dann nicht mehr so schnell auf Benutzereingaben reagieren – was bei einem Server wohl zu verschmerzen ist.

Realtime light

Die Prioritätsklasse SCHED_ISO stellt sozusagen eine gemäßigte Variante der Realtime-Priorität dar. Sie erfordert keine Root-Rechte, bietet aber auch nicht die höchsten Prioritäten. Versucht ein Benutzer ohne Root-Rechte, eine Anwendung mit Echtzeit-Priorität zu versehen, steckt ihn der Kolivas-Scheduler ihm automatisch in die SCHED_ISO-Klasse.

Im Test hat sich zur Einstellung der Priorität das Kommandozeilenprogramm schedtool bewährt. Damit starten Sie eine Anwendung mit der gewünschten Priorität:

schedtool -R -p 50 -e mplayer?
 file.avi

Der Schalter -R legt Echtzeit-Priorität fest, -p 50 den Wert. Fehlt die Option -e, erwartet Schedtool die ID eines laufenden Prozesses. Das Paket schedutils von Robert Love [7] erfüllt einen ähnlichen Zweck wie die Schedtools, beherrscht aber nicht alle Scheduler-Prioritäten.

Arbeit am Kernel

Im Test hat sich das Patchset von Con Kolivas als am wirkungsvollsten erwiesen. Damit gab MythTV einen vom Rechner decodierten DVB-Stream auch bei hoher Systembelastung frei von Bild- oder Tonaussetzern wieder. Da seine Änderungen bislang nicht Teil des Standard-Kernels sind, muss der Anwender seinen optimierten Kernel selbst übersetzen. Fedora-Nutzer finden unter [8] Binärpakete, die sich allerdings nicht auf dem neuesten Stand befinden. )ofr)