# Real-Time Linux: Determinismus statt purer Geschwindigkeit

TL;DR / Management Summary In der Standard-IT zählt Durchsatz. In der Welt der Industriesteuerungen, Robotik und Audio-Technik zählt Determinismus: Eine Aktion muss garantiert innerhalb einer bestimmten Zeit (z.B. 100 Mikrosekunden) ausgeführt werden. Ein Senior Admin nutzt den PREEMPT_RT Kernel-Patch, um Linux in ein Hard-Real-Time System zu verwandeln. Er opfert dabei Gesamtdurchsatz für garantierte Antwortzeiten.

# 1. Einführung & Architektur

Durchsatz vs. Latenz.

Ein normaler Kernel (Artikel 379) kann einen Prozess jederzeit unterbrechen (Preemption), außer er befindet sich in einem kritischen Bereich (Critical Section). Der RT-Kernel macht fast den gesamten Kernel-Code unterbrechbar.

# Der Architektur-Unterschied (Mermaid)

graph TD
    subgraph "Standard Kernel"
        A[App Request] --> B[Kernel: SoftIRQ / Spinlock]
        B -->|Wait| B
        B --> C[Execution]
    end
    subgraph "PREEMPT_RT Kernel"
        D[App Request] --> E[Kernel: Threaded IRQ / Sleepable Lock]
        E -->|Immediate Preemption| F[High Priority RT Task]
        F --> G[Execution]
    end
    B --- H[High Throughput / High Latency]
    E --- I[Lower Throughput / Guaranteed Latency]

# 2. Den RT-Status prüfen

Habe ich einen Echtzeit-Kernel?

Die meisten Distributionen bieten einen RT-Kernel als Paket an.

uname -a
# Achten Sie auf den String 'PREEMPT_RT'

# Installation (Beispiel Arch)

sudo pacman -S linux-rt linux-rt-headers

# 3. High-Resolution Timers

Präzision im Nanosekunden-Bereich.

Ein RT-Kernel nutzt hochauflösende Timer, um Prozesse exakt zu wecken.

cat /proc/timer_list | grep "resolution"
# In RT-Systemen sollte hier '1 nsecs' stehen.

# 4. Day-2 Operations: Priority Inheritance

Das Umkehren der Hierarchie verhindern.

Ein häufiges Problem in RT-Systemen ist die Priority Inversion: Ein niedrig-priorisierter Prozess hält ein Lock, das ein hoch-priorisierter Prozess braucht.

• Lösung: Der RT-Kernel nutzt “Priority Inheritance”. Der niedrige Prozess erbt temporär die hohe Priorität, um seine Arbeit fertigzustellen und das Lock freizugeben.

# 5. Troubleshooting & “War Stories”

Wenn ‘Echtzeit’ das System einfriert.

# Story 1: “Der total-Lockup durch FIFO”

Symptom: Der Server reagiert auf keine Tasteneingabe mehr, der Schirm ist eingefroren, aber der Cursor blinkt noch. Ursache: Ein Admin hat eine Endlosschleife (Bug) in einer Applikation, die mit SCHED_FIFO und Priorität 99 läuft. Da dieser Prozess die CPU niemals freiwillig abgibt, bekommt selbst der Kernel-Schreibprozess oder SSH keine Rechenzeit mehr. Lösung: Nutzen Sie beim Testen immer RT Throttling: sysctl -w kernel.sched_rt_runtime_us=950000. Dies reserviert 5% der Zeit für Notfall-Aufgaben.

# Story 2: “Das Latenz-Loch durch SMI”

Symptom: Trotz RT-Kernel gibt es alle 10 Minuten einen Latenz-Peak von 5 Millisekunden. Ursache: System Management Interrupts (SMI). Die Firmware (BIOS) des Mainboards übernimmt die CPU für interne Aufgaben (Lüftersteuerung, Thermal-Check). Der Kernel kann dies nicht unterbrechen. Lösung: Deaktivieren Sie Energiesparmodi (C-States) im BIOS und nutzen Sie Tools wie cyclictest, um die Hardware-Latenz zu messen.

# 6. Fazit & Empfehlung

• Wahl: Nutzen Sie PREEMPT_RT nur, wenn Ihre Applikation harte Deadlines hat. Für 99% aller Web- und Datenbank-Server ist der Standard-Kernel performanter.
• Wartung: Nutzen Sie CPU Isolation (isolcpus Boot-Parameter), um RT-Aufgaben komplett von Hintergrundprozessen zu trennen.
• Wissen: Echtzeit-Linux ist kein “schnelles” Linux, sondern ein “vorhersehbares” Linux.

# Anhang: Cheatsheet