💭 Jeremys Brain

realtime-PREEMPT_RT

3 min read

Echtzeit unter Linux – ein praxisnaher Überblick

Zielgruppe: System‑ & DevOps‑Admins, die harte oder weiche Echtzeit auf x86/ARM‑Linux implementieren wollen.
Scope: PREEMPT_RT im Mainline‑Kernel, BIOS‑Tuning, Task‑Priorisierung, Jitter‑Messung.
Ohne Container‑Themen.

1 | Warum überhaupt Echtzeit?

AnforderungLatenz‐BudgetJitter‐BudgetTypische Domäne
Audio‑Streaming 48 kHz≤ 5 ms< 50 µsDAW/Live‑Sound
Robotik‑Interpolation 1 kHz≤ 1 ms< 10 µsMotion‑Control
Schutzrelais 4 ms≤ 4 ms< 100 µsSafety

Latenz = absolute Verzögerung.
Jitter = Schwankung dieser Verzögerung.
⇒ Je kleiner beides, desto deterministischer die Anwendung.

2 | Linux‑Strategie: PREEMPT_RT (Realtime‑Patch)

Gerne, hier ist die überarbeitete Version auf Deutsch:

Was ist PREEMPT_RT?

PREEMPT_RT ist eine Erweiterung des Linux-Kernels, die nahezu alle Kernel-Abschnitte präemptiv (unterbrechbar) macht. Dies ermöglicht es höherpriorisierten Echtzeit-Threads, sofort zu laufen, selbst wenn der Kernel gerade mitten in einem Systemaufruf steckt.

Kernfunktionen

  • Vollständige Präemption: Kritische Kernel-Abschnitte wurden verkürzt, sodass der Scheduler fast überall unterbrechen darf.

  • RT-Mutex (statt Spinlock):

    • Spinlock: Ein Thread hält die CPU fest, wodurch andere Threads aktiv “warten” (busy-waiting).

    • RT-Mutex: Wartende Threads schlafen und der Lock-Besitzer erbt die höhere Priorität des wichtigsten Wartenden. Dies verhindert die Prioritätsinversion und hält die CPU frei.

  • Threaded IRQs: Interrupt-Handler laufen nun als Kernel-Threads und können über chrt priorisiert werden.

Praxiswerte (x86, bei sauberer BIOS-Optimierung)

  • Maximaler Jitter: Typischerweise 5-20 µs.

  • Verlässliche Zykluszeiten: ≥ 50 µs.

Verfügbarkeit

Seit Kernel 6.6 (Oktober 2023) ist PREEMPT_RT ohne zusätzlichen Patch direkt im Mainline-Kernel-Tree integriert. Du musst also nur noch das -rt-Kernel-Paket deiner Distribution installieren.

3 | Kernel & Pakete installieren

Debian/Ubuntu

sudo apt install linux-image-rt-amd64 linux-headers-rt-amd64
sudo reboot

Fedora/RHEL

sudo dnf install kernel-rt kernel-rt-devel
sudo grubby --set-default 0 && reboot

4 | BIOS-/UEFI‑Tuning (Hardware‑Ebene)

  1. Hyper‑Threading: Disable

  2. C‑States/Turbo: C0/C1 only, Turbo off

  3. HPET & TSC‑Deadline Timer: Enable

  4. SMM (SMI) Legacy USB u. Ä.: Disable

Ohne diese Schritte treten > 50 µs Jitter‑Peaks auf, egal wie “rt” der Kernel ist.

5 | Boot‑Parameter & CPU‑Isolation

# /etc/default/grub (Auszug)
GRUB_CMDLINE_LINUX="isolcpus=2-3 nohz_full=2-3 rcu_nocbs=2-3 mitigations=off"
update-grub && reboot

  • isolcpus – RT‑Cores, die CFS nicht anfasst.

  • nohz_full – Tick‑less Betrieb auf diesen Cores.

  • rcu_nocbs – verschiebt RCU‑Call‑backs auf andere Cores.

Check nach Boot:

lscpu | grep -E "CPU\(s\)|On-line"
cat /proc/cmdline

6 | RT‑Task einrichten

6.1 Capabilities & Limits

sudo setcap cap_sys_nice,cap_ipc_lock+ep /opt/bin/sensor_app
 
# /etc/security/limits.d/realtime.conf
@realtime  -  rtprio   95
@realtime  -  memlock  unlimited

Benutzer in Gruppe realtime:

sudo usermod -aG realtime $USER

6.2 Start mit fester Priorität

sudo chrt -f 90 taskset -c 2 /opt/bin/sensor_app

* sched_setscheduler(SCHED_FIFO, prio) via POSIX in C/C++
* mlockall(MCL_CURRENT|MCL_FUTURE); gegen Paging

7 | Jitter messen

sudo cyclictest -p95 -S -m -i1000 -h500 -q   # 1 kHz, 500 µs Deadline
 
# Ausgabe lesen
#  T: 0 (  954) P:95  I:1000 C:  6000 Min:      4 Max:     18 Avg:      7

  • Max = schlimmster Peak; sollte < Deadline sein.

  • Mit BIOS‑Feintuning sind 5 – 20 µs Peak‑to‑Peak erreichbar.

Weitere Tools:

sudo perf sched latency   # Scheduler-Latenzen
trace-cmd record -e sched_switch -e irq_handler_entry -e irq_handler_exit sleep 10
trace-cmd report | less   # Analyse

8 | Troubleshooting‑Snippets

SymptomSchnell‑CheckFix
Peaks > 100 µspowertop --time zeigt C‑State > C2BIOS → C‑States off; intel_pstate=disable
IRQ‑Stürme auf RT‑Corecat /proc/interruptsecho 0 > /proc/irq/XX/smp_affinity
Memory‑Lock refused`dmesggrep CAP_IPC_LOCK`

9 | Cheat‑Sheet für die Admin‑Konsole

# Kernel prüfen
uname -v | grep PREEMPT_RT
# Schnelles Jitter‑Assessment (1 min)
sudo cyclictest -q -p95 -d1s -h100
# Aktive Scheduler‑Klassen anzeigen
ps -eo pid,comm,cls,policy,rtprio,ni --sort=cls
# Thread live auf FIFO 90 heben
sudo chrt -f -p 90 <PID>

10 | Fazit

  • PREEMPT_RT bringt Echtzeit direkt in den Mainline‑Kernel – keine proprietären Co‑Kernel nötig.

  • < 20 µs Jitter sind mit aktuellem x86‑HW & sauberem BIOS‑Tuning erreichbar – für 90 % aller Industrie‑ und Audio‑Anwendungen ausreichend.

  • Für < 5 µs oder Zykluszeiten < 25 µs → Co‑Kernel (TwinCAT RT, RTX64) oder FPGA in Betracht ziehen.

Take‑away: Linux + PREEMPT_RT = offene, lizenzfreie Grundlage für deterministische Steuerung – mit wenigen Bash‑Befehlen kontrollierbar.

LinuxRealtimePREEMPTRTEchtzeitKernelRTLinuxJitterReductionLatencyTuningKernelTuningBIOSOptimierungHardRealtimeSoftRealtimeDevOpsLinuxCyclictest

Linux-Blog-Overview

Graph View