Linux in Mission Critical Systems einsetzen (Seite 3)

An dieser Stelle sei daran erinnert, dass eine Software nur dann eine niedrige Latenz aufweist, wenn man sie unter Realzeitgesichtspunkten programmiert und betreibt. Dazu gehört neben dem Vergeben einer Realzeitpriorität das zuverlässige Unterbinden von Speicherfehlern. Cyclictest bringt nicht nur solche Mechanismen mit, sondern ermöglicht auch, sie per Kommandozeilenoption ein- und auszuschalten. Die Wahl der Priorität spielt eine besonders wichtige Rolle. Mit dem PREEMPT_RT-Patch sind fast alle Interrupt-Service-Routinen als Interrupt-Threads ausgeführt und damit priorisiert. Sollen Interrupts nicht das Testprogramm selbst ausbremsen, müssen Sie die Priorität entsprechend hoch setzen.

Erkenntnisgewinn

Abbildung 6 zeigt den Aufruf von Cyclictest als normale Applikation, also ohne Priorität, Memory Prefault oder sonstige Realzeittechniken. Die Latenzzeiten liegen bereits recht passabel im zweistelligen Millisekundenbereich. Unter Last fallen sie niedriger aus als ohne Last. Das zunächst seltsam anmutende Phänomen hat mit häufiger auftretenden Unterbrechungen zu tun und dem damit verbundenen, zeitnäheren Abarbeiten von Zeitaufträgen und des Schedulings.

Abbildung 6: Auch ohne Realzeitprogrammierung lassen sich passable Latenzzeiten erreichen.

Starten Sie Cyclictest mit einigen Realzeittricks, liegen die Latenzen ebenfalls im zweistelligen Bereich – diesmal aber im Mikro- statt wie vorher im Millisekundenbereich (Abbildung 7). Das ist recht beeindruckend für den Raspberry Pi und das darauf laufende ausgewachsene Betriebssystem. Das Open Source Automation Development Lab (OSADL) nimmt Langzeitmessungen der Latenz von diversen Realzeit-Linuxen vor, bestätigt unser Ergebnis und liefert Plots dazu. Der Raspberry Pi 4 befindet sich in deren Testlabor in Rack 4, Slot 1 [7]. Das Team erstellt die Plots direkt mithilfe von Cyclictest und Gnuplot. Die Häufigkeitsverteilung der Latenzzeiten unserer Messungen auf den einzelnen CPU-Kernen finden sich in Abbildung 8.

Abbildung 7: Der PREEMPT_RT-Patch verkürzt die Latenzzeiten.

Abbildung 8: Die Häufigkeitsverteilung der Latenzzeitmessung.

Neugierige spielen noch etwas mit den Kommandozeilenoptionen und den Prioritäten. Reduzieren Sie beispielsweise die Priorität von 80 auf 10, bekommen wir auf Core 0 der RasPi-CPU eine dreistellige Latenzzeit – ein signifikantes Zeichen für Threaded Interrupts: Höher priorisierte Interrupt-Threads unterbrechen augenscheinlich die auf CPU-Kern 0 laufenden Tasks.

Aus diesen wenigen Tests lassen sich bereits eine Reihe von spannenden Erkenntnissen ableiten. An erster Stelle steht, dass Linux mit dem PREEMPT_RT-Patch tatsächlich erfreulich niedrige Latenzzeiten ermöglicht. An zweiter Stelle folgt, dass der Patch allein nicht genügt: Wer niedrige Latenzzeiten benötigt, der muss den Werkzeugkoffer der Realzeitprogrammierung öffnen und auf System und Applikation anwenden. Was die Toolbox so alles hergibt, lesen Sie bei Interesse kompakt im eingangs zitierten Reddit-Thread der SpaceX-Entwicklermannschaft nach. (csi)