Jahrelang existierte die "Realtime Preemptive"-Funktion (PREEMPT _RT) lediglich als Out-of-Tree-Erweiterung neben dem Mainline-Kernel. Gepflegt wurde sie von einer beharrlichen Gruppe um Thomas Gleixner, Ingo Molnár und Steven Rostedt, zwischenzeitlich unterstützt durch Ressourcen der Linux Foundation und OSADL (Open Source Automation Development Lab). Im September 2024 folgte der entscheidende Schritt: Mit Linux 6.12 gelangte die Echtzeitfähigkeit offiziell in den Kernel. Auf den Architekturen x86, x86_64, ARM64 und RISC-V aktivieren Admins das Feature seitdem über den Konfigurationsschalter "CONFIG_PREEMPT_RT" – ohne externe Patches oder manuelle Basteleien am freien Betriebssystem.

In der Praxis ändert diese Integration jedoch weniger, als es zunächst scheint. Wer in der Industrie, der Telekommunikation, im Finanzhandel oder in der Robotik deterministische Echtzeit (Real- Time; RT) benötigt, kompiliert den Kernel meist nicht selbst. Stattdessen setzen IT-Verantwortliche auf Distributionen, die passende Pakete liefern, den Kernel pflegen, Sicherheitsupdates bereitstellen und Support bieten, falls die Fertigung stockt oder eine SPS Pakete verliert. Gleichzeitig unterliegt der Markt für RT-Infrastrukturen einem Wandel, bei dem wenige große Distributoren kleine Anbieter mit proprietären Angeboten auf Basis externer Patches ablösen. Die Mainline-Integration stellt zudem die Zukunft rein proprietärer Anbieter infrage.

Bevor wir die Details betrachten, klären wir, was RT-Linux auszeichnet. Echtzeit bedeutet nicht zwingend hohe Geschwindigkeit, auch wenn das Marketing diesen Eindruck oft erweckt. Standarddistributionen nutzen meist einen auf maximalen Durchsatz optimierten Kernel. Der "Completely Fair Scheduler" (CFS) verteilt CPU-Zeit so, dass alle Prozesse zügig vorankommen. Für Webserver oder Datenbankhosts ist das ideal, da es dort kaum eine Rolle spielt, ob eine Antwort wenige Mikrosekunden früher oder später erfolgt.

In Echtzeitumgebungen zählt hingegen die garantierte maximale Antwortzeit eines Prozesses. Ein Industrieroboter muss zu einem exakten Zeitpunkt reagieren; Millisekunden an Verzögerung führen zu Fehlern oder Kollisionen. Im Hochfrequenzhandel entscheiden Mikro- sekunden über Gewinn und Verlust. In 5G-Setups der Telekommunikation bricht bei Überschreitung harter Latenzgrenzen die Verbindung zusammen.

Für diese Szenarien bietet die Realtime- Preemptive-Funktion spezifische Mechanismen. Preemption-fähige Mutexe mit Priority Inheritance ersetzen herkömmliche Spinlocks – sprich: Anstatt dass ein Prozess die CPU aktiv blockiert und auf eine Ressource wartet, wird er schlafen gelegt und erst dann wieder aufgeweckt, wenn die Sperre frei ist. Dabei hebt das System gleichzeitig die Priorität des sperrenden Prozesses kurzzeitig an, um Verzögerungen zu minimieren. Dies verhindert, dass hochpriorisierte Prozesse warten müssen, weil ein Prozess mit niedriger Priorität einen Lock hält. Interrupt-Handler lagert RT in eigene Threads aus ("Threaded Interrupts"), wodurch sie ein Scheduler verschieben kann. Hochauflösende Timer ("hrtimers") sowie ein – bis auf wenige Pfade – vollständig preemptierbarer Kernel ergänzen das System. So lassen sich spezifische Durchführzeiten für Aufgaben garantieren, notfalls zulasten anderer Prozesse.

Das Ergebnis ist ein Kernel, dessen reiner Durchsatz oft unter dem der Standard-Pendants liegt, der aber Worst-Case-Latenzen im niedrigen zweistelligen Mikrosekundenbereich liefert. Während ein Standard-Linux je nach Last zwischen Mikrosekunden und Millisekunden schwankt, bietet die RT-Variante die für CNC-Maschinen notwendige Konstanz.

Eine RT-Distribution umfasst mehr als nur den Kernel. Die Anbieter liefern notwendige Werkzeuge mit: Userspace-Tools wie "rt-tests" [1] inklusive "cyclictest" und "hwlatdetect", Tuning-Werkzeuge wie "TuneD" [2] und "tuna" [3] sowie echtzeittaugliche Bibliotheken. Zudem gehören ein vorkonfigurierter Bootloader für CPU-Isolation und Tickless-Modus sowie Profile zur Vermeidung von Konfigurationsfehlern zum Paket.

Kommerzielle Anbieter ergänzen dies durch Sicherheitsupdates, Support und Zertifizierungen für die Avionik, Medizintechnik oder den Maschinenbau. Diese Komponenten unterscheiden eine professionelle Umgebung von einem selbstgebauten Kernel auf einem Standard-Debian. Letzteres eignet sich für Experimente, wirft im produktiven Einsatz aber zu viele Probleme auf. Wir betrachten im Folgenden die Produkte, die sich am Markt etabliert haben.

In den Anfangstagen von Echtzeit-Linux im kommerziellen Umfeld stellte Red Hat mit "MRG" (Messaging, Real-time, Grid) unter RHEL 5 und 6 ein Produkt-Bundle bereit, das das damalige Linux-RT-Patchset unterstützte. Mit RHEL 7 änderte der Hersteller die Strategie und führte "RHEL for Real Time" [4] als eigenständiges Add-on ein, das Admins über ein dediziertes Repository zu einer regulären RHEL-Subskription hinzubuchen.

RHEL for Real Time gilt seither als Referenz unter den Enterprise-Distributionen. Das liegt zum einen an den massiven Investitionen in die Infrastruktur rund um den RT-Kernel. Werkzeuge wie TuneD mit spezifischen Echtzeitprofilen, das Tuning- Frontend "tuna" sowie diverse Latenzmess- routinen sind keine lose Paketsammlung, sondern integraler Bestandteil der Umgebung. Zum anderen beschäftigt Red Hat einflussreiche Kernelentwickler wie Steven Rostedt, die die Echtzeitfähigkeit im Mainline-Kernel maßgeblich vorantreiben.

Der RT-Kernel gelangt über das Repository "rhel-X-server-rt-rpms" auf das System (X steht für die jeweilige Major-Version). Nach der Buchung des Add-ons lässt sich über DNF das Paket "kernel-rt" installieren, inklusive der zugehörigen Werkzeuge. Ein Reboot aktiviert den neuen Kernel, der durch das Suffix "rt" in der Versionsnummer eindeutig erkennbar ist. Seit RHEL 9 liefert Red Hat zudem Werkzeuge zur Konfiguration des "SCHED_DEADLINE"-Schedulers aus.

Das System arbeitet zuverlässig und bietet eine saubere Dokumentation für Latenzmessung und Tuning. Die tiefe Integration in RHEL-Werkzeuge wie "TuneD", "systemd" und "Cockpit" erleichtert die Verwaltung. Lange Supportzyklen von zehn Jahren pro Major-Version sowie zahlreiche Zertifizierungen für Hardware im Telekommunikations- und Finanzsektor sprechen für das Produkt. IT-Profis profitieren zudem vom direkten Zugriff auf das Know-how der Kernelentwickler.

Nachteilig wirkt sich das kostenintensive Subskriptionsmodell aus, da die RT-Variante ein zusätzliches Add-on erfordert. Wie bei RHEL üblich, müssen Admins Kernelmodule von Drittanbietern explizit für den RT-Kernel kompilieren. Dies schränkt die Hardwareauswahl ein und kann den Support durch Red Hat erschweren.

Canonical adressierte den RT-Markt vergleichsweise spät, dafür aber mit Nachdruck. Die Entwicklung begann 2022 mit Ubuntu 22.04 LTS, für das erstmals ein offizieller RT-Kernel über das Pro-Modell verfügbar war. Zuvor bot Ubuntu lediglich einen Lowlatency-Kernel an, der für Audio-Produktionen ausreicht, aber keine echte PREEMPT_RT-Funktionalität besitzt.

Mit Ubuntu 24.04 LTS und dem darauf basierenden "Real-time Ubuntu" [5] hat der Anbieter das Portfolio erweitert. Der RT-Kernel nutzt Upstream-Linux 6.8 mit den klassischen PREEMPT_RT-Patches und unterstützt AMD64 sowie ARM64. Canonical bietet zudem optimierte Varianten für Intels 12th-Gen-Plattformen mit "Time Coordinated Computing" (TCC) und "Time Sensitive Networking" (TSN) an. Ein Alleinstellungsmerkmal ist die Unterstützung für Raspberry Pi 4 und 5. Wer Embedded-Gateways oder Steuergeräte auf Raspi-Basis betreibt, erhält damit eine kommerziell unterstützte RT-Infrastruktur. Die Installation erfolgt sehr einfach über den "pro"-Client und nach einem Reboot ist das System einsatzbereit. Spezielle Varianten für Intel-SoCs oder den Raspberry Pi lassen sich über zusätzliche Optionen beim Aktivierungsbefehl auswählen.

Das Lizenzmodell ist für Entwickler attraktiv: Ubuntu Pro ist für die private Nutzung und kleine kommerzielle Umgebungen mit bis zu fünf Maschinen kostenfrei. Für größere Umgebungen fallen Subskriptionsgebühren an, die sich nach der Anzahl der Systeme richten. Canonical garantiert bis zu zwölf Jahre Sicherheitssupport für LTS-Versionen. Ein Vorteil gegenüber anderen Ansätzen ist, dass die reguläre Ubuntu-Toolchain vollständig nutzbar bleibt und kein Wechsel innerhalb der Distribution nötig ist.

Es gibt jedoch Einschränkungen: Die Bindung an Ubuntu Pro erfordert eine Onlineaktivierung, was in Air-Gap-Szenarien den Konfigurationsaufwand erhöht. Zudem ist die Infrastruktur inkompatibel mit der Live-Patch-Funktion und NVIDIA-Treibern. Wer KI-Workloads mit Echtzeit kombinieren möchte, ist auf GPUs angewiesen, deren Treiber im Grundsystem enthalten sind. Da Ubuntu erst seit Kurzem am RT-Markt agiert, fehlen Langzeiterfahrungen bezüglich der Supportqualität. Zudem bietet Canonical derzeit weniger Drittanbieter-Zertifizierungen für spezifische Industrieumgebungen als Red Hat.

Im deutschsprachigen Raum ist SUSE fest etabliert und blickt auf eine lange Historie im RT-Bereich zurück. Die Wurzeln liegen in der Novell-Ära, als "SUSE Linux Enterprise Real Time" (SLERT) [6] als Add-on für SLES 10 erschien. Damals stammte die Technologie von Concurrent Computer. Mittlerweile pflegt SUSE das Produkt selbst und setzt unter der Haube auf die regulären PREEMPT_RT-Patches. Das aktuelle Produkt fungiert als Add-on für den SUSE Linux Enterprise Server (SLES). Es enthält die üblichen Komponenten: einen vorkonfigurierten Preemptible-Kernel, Werkzeuge für Latenzmessung, Priority Inheritance, CPU Shielding sowie Interrupt-Threads. Drittanbieter-Module müssen auch hier separat gebaut werden; die Unterstützung variiert je nach Hardwarehersteller stark.

Äußerst interessant ist die Verknüpfung mit SUSEs Fokus auf "Immutable"-Distributionen. Mit MicroOS und SUSE Linux Micro existiert eine schlanke Plattform mit transaktionalen Updates, die zunehmend RT-Funktionen integriert. Für Edge-Anwendungen ist dieser Ansatz vorteilhaft, da atomare Snapshots das Risiko minimieren, dass ein Update die Industrieanlage lahmlegt.

SLERT punktet durch ausgereifte Produkterfahrung und eine gute Integration in Werkzeuge wie "YaST" und den "SUSE Manager". Ein wichtiges Argument in der Industrie ist die traditionell enge Verzahnung mit SAP-Workloads. Der verfügbare deutschsprachige Support rundet das Angebot ab. Allerdings erreicht SUSE global einen geringeren Marktanteil als Red Hat, weshalb für SLERT weniger Drittanbieter-Zertifizierungen vorliegen. Wie bei den Wettbewerbern führt das Subskriptionsmodell auch hier zu deutlichen Mehrkosten gegenüber der Standarddistribution.

Während RHEL, Ubuntu und SLES um Marktanteile in Rechenzentren konkurrieren, agiert Wind River Linux [7] in einer eigenen Kategorie. Der Anbieter aus Kalifornien hat sich seit 1981 als Marktführer für Embedded-Echtzeitsysteme etabliert und erlangte Bekanntheit durch das proprietäre Betriebssystem VxWorks, das in der Avionik, Verteidigung und Industrie zum Einsatz kommt.

Wind River Linux unterscheidet sich grundlegend von klassischen Distributionen. Es existiert keine fertige ISO-Datei, stattdessen dient ein Distribution Builder auf Basis des Yocto Project (siehe auch Kasten) als Grundlage. IT-Profis bauen sich ihre Infrastruktur für die Zielhardware passgenau zusammen. Dieser Ansatz erfordert mehr Aufwand als eine Standard- installation, bietet im Embedded-Bereich aber Vorteile: Der Footprint lässt sich minimieren, da Admins jede Bibliothek und jeden Treiber gezielt auswählen.

Echtzeit ist bei Wind River Linux ein zentraler Baustein. Der RT-Kernel mit PREEMPT_RT ist ebenso integriert wie Funktionen zur Systemhärtung und Werkzeuge für das CVE-Tracking. Das Long-Term-Support-Modell bezeichnet der Anbieter als "Military Grade Linux". Wer bereits Erfahrung mit Yocto besitzt, findet sich schnell zurecht; Umsteiger von Ubuntu oder RHEL müssen jedoch eine Einarbeitungszeit einplanen.

Für Industrieanwendungen stellt Wind River zahlreiche Zertifizierungen bereit (ISO, IEC, FDA, DO-178). Das Produkt lässt sich zudem mit VxWorks und Wind River Studio kombinieren. Finanziell ist die Umgebung im oberen Segment angesiedelt, da es sich um ein hochspezialisiertes Werkzeug handelt. Der Fokus liegt klar auf Embedded Linux – für klassische Server-Workloads ist die Infrastruktur weniger geeignet. Zudem erschwert die spezialisierte Toolchain die Suche nach qualifizierten Fachkräften.

Eine pragmatische Option bietet Debian. Das Projekt stellt seit Jahren einen offiziellen RT-Kernel bereit, der sich über die Pakete "linux-image-rt-amd64" oder "linux-image-rt-arm64" [8] installieren lässt. Das Kernelteam integriert die PREEMPT_RT-Patches in die aktuelle Version und liefert sie über die regulären Quellen aus. Durch die Mainline-Inte- gration ab Linux 6.12 entfällt künftig das aufwendige Einbinden externer Patches.

Mit Debian Bookworm oder Trixie erhalten Anwender eine RT-fähige Umgebung ohne Lizenzkosten und Herstellerbindung. Werkzeuge zur Latenzmessung wie "rt-tests", "tuna" oder "stress-ng" stehen als Pakete bereit. Die Konfiguration erfordert allerdings deutlich mehr Eigenleistung als bei kommerziellen Produkten. Dieser Weg empfiehlt sich primär für Forschungseinrichtungen, interne Tests und Eigenentwicklungen. Da Debian keinen kommerziellen Support oder SLAs bietet und die Support-Zeiträume kürzer ausfallen, müssen Admins den Pflegeaufwand selbst leisten.

Die Integration von PREEMPT_RT in Linux 6.12 verändert das Ökosystem, doch die Wahl der Distribution bleibt an den Einsatzzweck gebunden. In Enterprise- Umgebungen mit Fokus auf Hochverfügbarkeit, etwa im Finanzsektor oder der Telekommunikation, bleiben RHEL for Real Time und SUSE Linux Enterprise Real Time die gesetzten Standards. Sie bieten Support, Zertifizierungen und eine integrierte Werkzeugkette.

Im Embedded-Bereich ist Wind River Linux bei zertifizierungspflichtigen Anwendungen führend. Wer über Yocto-Expertise verfügt, baut seine Umgebung selbst, trägt dann aber das Risiko für die Wartung. Ubuntu adressiert mit seinem Pro-Modell erfolgreich Entwickler und kleinere Unternehmen sowie spezialisierte Gateways auf Raspberry-Pi-Basis. Ob sich Canonical damit langfristig gegen die etablierte Konkurrenz im Industriesektor durchsetzt, bleibt abzuwarten. Debian bleibt die bevorzugte Wahl für kostenbewusste Projekte und Forschung ohne Supportbedarf. Die Entscheidung für eine Distribution hängt letztlich weniger von der Technik als von Supportverträgen, Hardware-Zertifizierungen und der bestehenden Anbieterbindung ab. IT-Verantwortliche haben heute jedoch eine größere Auswahl als je zuvor.