Software Echtzeit im Echtheits-Test

Für die „Stiftung Warentest“ sind Embedded-Prozessoren wohl etwas zu speziell. Das Team des Open Source Automation Development Lab kennt sich damit besser aus. In einem Testlabor laufen 24 Prozessoren ver-schiedenster Leistungsklassen und Architekturen. Neben dem Beweis der Echtzeit-Fähigkeit von Linux entsteht als Nebenprodukt ein architektur-übergreifender Prozessor-Benchmark. Die Ergebnisse sind mindestens so spannend wie die Veröffentlichungen der „Warentester“.

Beim Kernel-Summit in Ottawa im Jahre 2006 wurde beschlossen, komplett deterministische Echtzeit-Fähigkeit in den Hauptentwicklerzweig des Linux-Kernels (Mainline-Linux) aufzunehmen. Seitdem wurde eine große Anzahl an Echtzeit-Komponenten für Mainline-Linux bereitgestellt und von Linus Torvalds in den Kernel aufgenommen: 

  • Mutexe mit Priority-Inheritance,
  • hochauflösende Timer,
  • preemptives RCU (Read-Copy Update),
  • Interrupt-Threads,
  • Spinlock-Kategorisierung nach Unterbrechbarkeit. 

Hiermit und im Zusammenspiel mit weiteren Komponenten lassen sich Linux-Kernel mit Echtzeit-Fähigkeit für die Architekturen x86, ARM, PowerPC, MIPS und 68k herstellen. Ziel der Entwicklung ist es, dass mit diesen Kerneln ausgerüstete Systeme unter allen Umständen mit einer hinreichenden statistischen Wahrscheinlichkeit in einer vorher definierten Maximalzeit auf externe Ereignisse reagieren.

Damit sollen diese eine wesentliche Voraussetzung für den Einsatz in der Automatisierungsindustrie erfüllen und allgemein für Bedingungen geeignet sein, bei denen harte Echtzeit gefordert wird. Aber ist dies wirklich so? Wer überprüft die Echtzeit-Fähigkeit eigentlich, und wer sorgt dafür, dass eventuell nötige Korrekturen vorgenommen werden?  

Open Source garantiert hohe Code-Qualität

Es ist wohl unbestritten, dass die hohe Code-Qualität des Linux-Kernels in besonderem Maße dem Open-Source-Entwicklungsverfahren zu verdanken ist. Und dieses ist unter anderem eine Folge der im Linux-Kernel verwendeten Lizenz, der GNU General Public License (GNU GPL). Diese Lizenz fordert, dass bei Weitergabe des Linux-Kernels dessen Quell-Code offengelegt werden muss - und damit auch alle möglicherweise vorgenommenen Verbesserungen und Erweiterungen in den Hauptentwicklerzweig zurückfließen können.

Ein anderer Grund für die hohe Code-Qualität liegt im mehrstufigen, weltweit öffentlichen Begutachtungsverfahren, den eine Code-Änderung oder ein neuer Code durchlaufen müssen, bevor schließlich die Aufnahme in einen Release-Kandidaten erfolgt. Bis zum Release dauert es dann noch einmal etwa zehn Wochen mit etwa sechs bis acht weiteren Release-Kandidaten. In dieser Zeit wird der neue Kernel kontinuierlich getestet und korrigiert. Danach liegt ein stabiler und für Produktionszwecke verwendbarer Kernel vor. Allerdings gilt dies nicht notwendigerweise auch für die Echtzeit-Fähigkeit. 

Im Gegensatz zu den relevanten Testkriterien des nicht echtzeit-fähigen Standardkernels stellt die Echtzeit-Fähigkeit eine besondere Herausforderung an die Testumgebung dar. Während nämlich beim Standardkernel statische Tests im Vordergrund stehen - also die kurzfristige Überprüfung der grundsätzlichen Eigenschaften von Kernel und Treibern -, müssen bei der Überprüfung des Determinismus über einen längeren Zeitraum möglichst viele unterschiedliche Bedingungen im Zusammenspiel der einzelnen Kernel-Komponenten geschaffen und dabei die Echtzeit-Parameter mit möglichst hoher Messfrequenz bestimmt werden. Dies kann bedeuten, dass mehrere Milliarden Einzelmessungen erforderlich sind, so dass eine Messdauer von mehreren Tagen oder sogar Wochen resultiert.

Derartig intensive Tests können von den Entwicklern des Standard-Kernels naturgemäß nicht in voller Bandbreite geleistet werden; dies muss vielmehr von der relativ kleinen Gruppe von Anwendern, die an der Echtzeit-Fähigkeit des Kernels interessiert sind, selbst organisiert werden. Aus diesem Grunde hat sich eine Reihe von Firmen, die an der Verfügbarkeit eines echtzeit-fähigen Linux-Kernels interessiert sind, in einer Organisation zusammengeschlossen: Sie sorgt gemeinsam dafür, dass die Echtzeit-Fähigkeit des Linux-Kernels gemessen, kommuniziert und garantiert wird.

Bei dieser Organisation handelt es sich um das Open Source Automation Development Lab (OSADL), und das Echtzeit-Testzentrum heißt „QA Farm Realtime“. In dieser Farm wird eine große Anzahl verschiedener Systeme unter einer Vielzahl von System- und Lastbedingungen kontinuierlich auf ihre Echtzeit-Fähigkeit getestet. Viele relevante Messergebnisse werden kontinuierlich im Internet für jedermann verfügbar gemacht. Nur spezielle Messergebnisse, die z.B. für Zertifizierungen spezieller Gerätekombinationen verwendet werden können, sind exklusiv den jeweiligen OSADL-Mitgliedsfirmen zugänglich.  

Kernel-Messung mit Bordmitteln

Der echtzeitfähige Linux-Kernel bietet eine große Anzahl eingebauter Dia-gnose-Systeme, von denen einige zur Messung der Echtzeit-Eigenschaften verwendet werden können. Dabei handelt es sich im Speziellen um 

  • Wakeup-Latenz,
  • Timer-Offset und
  • Summe von Timer-Offset und Wakeup-Latenz

Wenn ein Prozess lauffähig geworden ist und in die Warteschlange eingefügt wird, z.B. weil ein Interrupt eingetroffen ist oder weil ein anderer, höher priorisierter Prozess keine Rechenzeit mehr beansprucht, wird die aktuelle Uhrzeit bestimmt und gespeichert. Wenn der lauffähig gewordene Prozess ein wenig später erfolgreich aktiviert wurde und tatsächlich Rechenzeit erhält, wird die aktuelle Uhrzeit wiederum bestimmt und die Dauer zwischen der aktuellen und der gespeicherten Uhrzeit berechnet.

Unter der Bedingung, dass der beobachtete Prozess die höchste Priorität des Systems hat und während des gesamten Aufweckvorgangs kein anderer Prozess mit dieser oder einer höheren Priorität Rechenzeit benötigt, kann die berechnete Zeitdauer als zu diesem Zeitpunkt wirksame Wakeup-Latenz des Systems betrachtet werden. Die berechnete Zeitdifferenz wird sodann in einem kernel-internen Histogramm gespeichert, das nach einer genügend langen Messdauer ausgewertet werden kann.

Bei dieser Auswertung wird der höchste jemals gemessene Wert bestimmt; als maximale Wakeup-Latenz des Systems („worst-case wakeup latency“) stellt dieser Wert zwar nur eine eingeschränkte Kenngröße eines Echtzeit-Systems dar, wird aber häufig verwendet und deswegen zu Vergleichszwecken auch hier angegeben. Die Granularität und damit die Messgenauigkeit aller Kernel-Histogramme beträgt 1 µs, der Messbereich 0 bis 10,24 ms. Der letzten Histogrammzelle kommt dabei eine besondere Bedeutung zu, denn hier werden alle Werte von 10,24 ms und höher eingetragen, so dass diese Zelle als Überlauf-Indikator fungiert. Nur wenn kein Überlauf eingetreten ist, darf das Histogramm tatsächlich für Analysezwecke verwendet werden.

In einigen Fällen wird ein Prozess nicht deswegen lauffähig, weil ein anderer, höher priorisierter Prozess keine Rechenzeit mehr beansprucht, sondern weil ein Interrupt eingetroffen ist - z.B. ausgelöst von einem Kommunikationscontroller im Falle von empfangenen Daten oder von einem Timer, wenn ein Alarm aufgesetzt wurde. In diesem Fall wird die Latenz nicht nur von der Wakeup-Latenz, sondern auch von einer eventuellen Verspätung des Timer-Interrupts und dessen Verarbeitung („Timer-Offset“) bestimmt. Daher verfügt der Echtzeit-Linux-Kernel über ein weiteres internes Histogramm. In dieses Histogramm wird jede Verspätung eingetragen, die sich aus der Differenz zwischen der aktuellen und der geplanten Uhrzeit eines Timer-Interrupts ergibt.

Schließlich ist im Echtzeit-Linux-Kernel noch ein drittes Histogramm vorgesehen, in welchem die Summe einer eventuellen Timer-Verspätung und der Wakeup-Latenz eingetragen wird. Diese Summe reflektiert die aktuell wirksame Gesamt-Latenz des Systems.

Als Ergebnis darf aber wiederum nicht ein einmalig gemessener Wert verwendet werden. Es muss vielmehr über einen sehr langen Zeitraum bei möglichst vielen unterschiedlichen Zuständen des Systems gemessen werden, damit der höchste jemals gemessene Wert als einzig relevante Kenngröße eines Echtzeit-Systems, nämlich als maximale Gesamt-Latenz („worst-case latency“), ermittelt und bei der System-Integration verwendet werden kann. Bei schnellen Prozessoren mit für Echtzeit gut geeigneten Systemkomponenten kann die maximale Gesamt-Latenz nur wenige Mikrosekunden betragen; in anderen Fällen liegt sie bei bis zu 400 Mikrosekunden.