Technische Kernaussagen
- PREEMPT_RT allein verfehlte auf beiden Pilotgeräten das maximale Jitter-Kriterium von einer Millisekunde.
- PREEMPT_RT plus SCHED_FIFO Priorität 80 bestand vier stationäre Läufe mit und ohne definierte Last.
- Das Ergebnis gilt für ein enges 10-ms-Pilotprofil und ist keine allgemeine Echtzeit- oder Sicherheitsfreigabe.
Jitter ist eine Verteilung, kein Adjektiv
Ein Linux-System ohne Periode, Last, Laufzeit und Maximalwert als deterministisch zu bezeichnen, ist Marketing. Entscheidend ist, ob der beobachtete Worst Case innerhalb des Zeitbudgets der Maschine bleibt.[3][4][5]
PREEMPT_RT macht mehr Kernel-Pfade unterbrechbar; SCHED_FIFO verändert, welcher lauffähige Prozess Vorrang erhält. Beides adressiert unterschiedliche Teile desselben Timing-Problems.[2][3]
Akzeptanzkriterien vor dem Test festlegen
Bestanden war der 10-ms-Lauf nur bei maximal 1 ms Jitter, null verpassten und überlaufenen Zyklen, höchstens 20 ms Snapshot-Alter, maximal 1 ms Veröffentlichungsdauer und höchstens 2048 KB Speicherwachstum.[1]
Die bestandene Konfiguration
PREEMPT_RT mit SCHED_FIFO Priorität 80 bestand auf beiden Controllern. Der maximale Jitter der vier Läufe lag zwischen 0,063612 ms und 0,094448 ms; verpasste Zyklen, Overruns und Speicherwachstum blieben bei null.[1]
| Controller | Last | Max. Jitter | Snapshot-Alter | Publikation | Verpasst / Overrun |
|---|---|---|---|---|---|
| A | Nein | 0,085877 ms | 1,982421 ms | 0,096610 ms | 0 / 0 |
| B | Nein | 0,063612 ms | 9,277714 ms | 0,064073 ms | 0 / 0 |
| A | Ja | 0,094448 ms | 3,851881 ms | 0,081295 ms | 0 / 0 |
| B | Ja | 0,067025 ms | 9,068315 ms | 0,079147 ms | 0 / 0 |
Die Fehlschläge erklären den Erfolg
Stock- oder Tuning-Konfigurationen erreichten 2,258783 bis 3,662989 ms. PREEMPT_RT ohne FIFO verbesserte das Ergebnis, scheiterte aber mit 1,014743 und 1,340064 ms weiterhin am Grenzwert.[1][2][3]
- Die gesamte Scheduling-Konfiguration messen, nicht nur den Kernel.
- Netzwerk, Logging und blockierende I/O aus dem zyklischen Thread halten.
- Fehlgeschlagene Läufe zusammen mit den Bestwerten archivieren.
Was bewiesen ist und was nicht
Die Daten rechtfertigen die Fortsetzung der 10-ms-Pilotstudie. Sie beweisen weder finale Freigabe noch I/O-Timing, Langzeitverhalten, Wertkorrektheit oder Safety-Eignung.[1]
Offen bleiben Kaltstart unter Last, 100-ms-Profile, Service-Konkurrenz auf demselben Kern, Backend-Freshness und Ende-zu-Ende-Wertprüfung.[1]
Der nächste Test muss das Ergebnis angreifen
- Kaltstart mit gleichzeitig einsetzender CPU-, Speicher- und Netzlast testen.
- Service und Runtime auf demselben Kern gegeneinander laufen lassen.
- Langläufe mit Temperatur, Log-Rotation und Reconnects durchführen.
- Physische I/O zusätzlich zu Software-Zeitstempeln messen.
- Rohdaten, Konfiguration und Fehlschläge veröffentlichen.
Häufig gestellte Fragen
Garantiert PREEMPT_RT deterministische Steuerung?
Nein. Kernel, Hardware, Treiber, Prioritäten, Last und Anwendungsdesign bestimmen gemeinsam das messbare Ergebnis.
Warum SCHED_FIFO für die Runtime?
Ein höher priorisierter Steuerungsthread kann normale Aufgaben verdrängen. Dafür muss seine Arbeit begrenzt und überwacht sein.
Sind die Ergebnisse eine Produktionsfreigabe?
Nein. Es sind vier stationäre Pilotläufe auf zwei Geräten mit klar veröffentlichten Lücken.
Quellen und Standards
- MCR Demo 1 steady-state 10 ms timing evidenceBootCtrl, 26 July 2026
- PREEMPT_RT theory of operationLinux kernel documentation
- sched(7): overview of CPU schedulingLinux man-pages project
- clock_nanosleep(2): high-resolution process sleepLinux man-pages project
- Cyclictest documentationLinux Foundation Real-Time Linux project
BootCtrl Engineering hat die technischen Aussagen und Quellenlinks zuletzt am 26. Juli 2026 geprüft. Produktaussagen werden mit den aktuellen Implementierungs-Repositories abgeglichen; Roadmap-Arbeit wird nicht als verfügbare Funktion dargestellt.
