innovative steuerungstechnik und mehr ...

Benchmark für Realtime Linux

verfügbar für Xenomai, RTAI und RT Preemption Patch - Kernel 2.4x und 2.6x


Veröffentlichung aus:
Computer & Automation 11/2007, WEKA Fachmedien GmbH
Link zum Fachartikel

Echtzeit-Linux auf dem Prüfstand

Xenomai, RTAI und der RT-Preempt-Patch sind die populärsten Echtzeit-Lösungen für Linux. Bis dato nur schwer objektiv zu vergleichen, quantifiziert Yellowstone Soft mit einem Benchmark die Stärken und Schwächen der Systeme.
Bei der Konzeption eines Embedded-Systems mit Linux stellt sich fast immer die Frage: Welche Echtzeit-Erweiterung harmoniert am besten mit der verfügbaren Hardware und der Applikation? Bei der Auswahl spielen unter anderem die Geschwindigkeit der Interprozesskommunikation, die Interrupt-Reaktionszeit und die maximale Periodizität des Prozess-Schedulings eine Rolle. Um die Systemauswahl auf Fakten zurückzuführen, hat Yellowstone Soft eine Testumgebung entwickelt und die drei Echtzeit-Ansätze RTAI (Realtime Application Interface), Xenomai sowie den Linux-RT-Preempt-Patch analysiert.

RTAI wurde als eines der ersten Echtzeitansätze für Linux 1999 an der Technischen Universität Mailand als Open Source Projekt gestartet. Xenomai wurde 2001 unabhängig von Rtai begonnen, 2003 mit Rtai zu RTAI/FUSION verschmolzen, aber seit 2005 wieder separat weiterentwickelt. Der RT-Preempt-Patch wird in Deutschland von der OSADL (Open Source Automation Development Lab) vorangetrieben um ihn schliesslich komplett in den Mainline Linuxkernel zu integrieren.

Die Testumgebung basiert auf dem Open Realtime Framework (ORF), einer standardisierten API für Echtzeitanwendungen, die als Open Source verfügbar ist und alle drei Echtzeit-Erweiterungen sowie verschiedene Hardware-Plattformen unterstützt.

Die sechs Test-Szenarien

Die Vergleichsmessungen sind den typischen Anforderungen der Automatisierungs- und Steuerungstechnik nachempfunden. Da eine Steuerung ständig Signale aus dem Prozess erfassen und ausgeben muss, wird auch bei den Benchmark-Untersuchungen immer ein komplettes Embedded-System - vom Signaleingang über die Verarbeitung in der CPU bis zum Setzen der Ausgänge - untersucht. Als Messinstrument kommt ein programmierbares Speicher-Oszilloskop mit einer grafischen Bedienoberfläche und einer C-API (Application Programming Interface) zum Einsatz. Bislang wurden mit der API sechs Benchmark-Tests programmiert und in das Oszilloskop integriert:

• Interrupt-Latenz
• Jitter
• Funktionsprüfung des prioritätsbasiertem Schedulers
• Verhalten bei Überlast
• Taskwechsel-Frequenz
• Interprozesskommunikation zwischen Kernel- und Userspace

Die Interrupt-Latenz, das heißt die maximale Zeit bis das System auf einen Interrupt reagiert, ist einer der wichtigsten Parameter bei Echtzeitsystemen. Die Interrupt-Latenz wird mit einer Interrupt Service Routine (ISR) ermittelt, die einen Signalwechsel auf einem Ausgang auslöst, sobald der Eingang einen Signalwechsel registriert. Das Speicher-Oszilloskop misst die Zeitdifferenz zwischen den Signalwechseln am Eingang und am Ausgang. Über längere Zeit erfasst, lässt sich so die maximale Interrupt-Latenz bestimmen.
Eine weitere wichtige Kenngröße für ein Echtzeitsystem, besonders bei ständig wiederkehrenden Aufgaben ist der Jitter, die zeitliche Abweichung eines periodischen Threads. Ein Thread ist ein zusätzlicher Ausführungsstrang in einem Programm, Echtzeitfunktionalität werden üblicherweise in einem solchen implementiert. Um den Jitter zu ermitteln, wechselt die Testapplikation des Embedded-Systems den Signalpegel eines Ausgangs in festen Zeitintervallen. Anhand dieses Rechtecksignals erfasst das Oszilloskop die Zeitdauer zwischen den Signalwechseln und analysiert dessen Schwankungen - den Jitter.
Für die qualitative Prüfung des prioritätsbasierten Schedulers werden vier Threads generiert und mit aufsteigender Priorität auf dem Probanten gestartet. Jeder Thread beansprucht für eine bestimmte Zeit im Bereich von 40µs bis 100ms die komplette Rechenleistung. Die Umschaltzeiten zwischen zwei Threads lassen sich über jeweils zwei Ausgänge erfassen: Der erste Ausgang (Active-Signal) signalisiert die Anforderung der Zeitscheibe durch den Threat, der die Zugriffsrechte aber aufgrund der "Preemption" (Bevorrechtigung) einer höher priorisierten Task nicht unbedingt bekommt. Der zweite Ausgang (Running-Signal) zeigt, ob die CPU diesen Thread tatsächlich bearbeitet. Durch diese Zuordnung lässt sich die Funktionalität des prioritätsbasierten Schedulings beurteilen. Um die Messzeit auf wenige Minuten zu minimieren wurden die Periodendauer und die Dauer, die jeder Thread die volle Rechenleistung beansprucht so gewählt, dass die Threads sich möglichst oft unterbrechen.
Das Oszilloskop erfasst dazu, welcher Thread wie oft und von wem unterbrochen wurde. Eine Unterbrechung des Threads trifft zu, wenn dessen Active-Signal auf High steht, das Running-Signal jedoch auf Low. Der für die Unterbrechung verantwortliche Thrad lässt sich über dessen Running-Signal ermitteln.
Das Überlast-Verhalten des Zielsystems wird ebenso in einem qualitativen Test geprüft. Ausgangspunkt der Untersuchungen ist ein "Normallast-Thread", der in periodischen Abständen die CPU kurzzeitig zu 100% belastet. Über eine Periodendauer betrachtet belegt dieser Normallast-Thread etwa 50 % der Rechenzeit. Um kurzzeitige Überlastzustände zu generieren, wird ein zweiter Thread gleicher Priorität mit langen Ruhepausen gestartet. Dieser Überlast-Thread ist so programmiert, dass die Rechenzeit, die er beansprucht länger ist, als die Pause zwischen zwei Ausführungen des Normallast-Threads. Dies zwingt den Scheduler die Ausführung des Normallast-Threads zu verzögern. Jeder Thread schaltet einen Ausgang des Systems auf High solange er die CPU belegt. Darüber lässt sich kontrollieren, ob beide Threads trotz der Überlast weiterhin ausgeführt werden.
Die Ausführungsfrequenz einer Task wird hauptsächlich durch die Taskwechsel-Zeiten und die Rechenleistung der Hardware begrenzt. Um die Periodizität zu testen, wird auf dem Echtzeit-System ein Thread mit steigender Frequenz gestartet, welcher das Signal eines Ausgangs invertiert. Das resultierende Rechtecksignal wird vom Oszilloskop auf Fehler überprüft, um die höchste fehlerfreie Frequenz zu ermitteln.
Der Benchmark Interprozesskommunikation hat weniger mit der Echtzeitfähigkeit eines Systems zu tun, sie bildet allerdings die Schnittstelle zum Echtzeit-System. Der Benchmark ermittelt die Geschwindigkeit, mit der Daten zwischen Echtzeit-System und den nicht unter Echtzeit laufenden Programmteilen übertragen werden. Da hierfür auch in der tatsächlichen Anwendung keine Hardware Ein- und Ausgänge verwendet werden, wird auf die Messung durch ein externes Oszilloskop verzichtet. Vielmehr werden stetig Pakete vom User-Space in den Kernel-Space und zurück kopiert und über ein Zeitintervall erfasst. Die ermittelte Paketanzahl ist ein Maß für die Geschwindigkeit der Interprozesskommunikation.

Die Ergebnisse der Benchmark

Anhand der Benchmarks wurden bereits verschiedene Kombinationen aus Hardware, Echtzeit-Erweiterung und Linux-Kernelversion getestet: Auf PowerPC-Boards wurde Xenomai in Verbindung mit einem Linux-Kernel der 2.6er Serie sowie RTAI in Verbindung mit Linux 2.4 untersucht. Xenomai/Linux-2.6, RTAI/Linux-2.6 und RTAI/Linux-2.4 wurden auf diversen Intel-Architekturen evaluiert. Der Preempt-Patch wurde in Verbindung mit einem 2.6er Linuxkernel auf einer Intel Architektur evaluiert.
Um festzustellen, wie sich die Echtzeit-Systeme unter Last verhalten, wurden alle Tests sowohl im Leerlauf als auch bei hoher Prozessor-Auslastung durchgeführt. Es werden 3 Programme gestartet, die jeweils 100% CPU nutzen um Daten von einem Pseudo Gerät ins andere zu kopieren. Ein remote gestarteter Ping flood sorgt dafür, dass die Netzwerkkarte des Echtzeitsystemes etliche Interrupts wirft, was nochmal ein beträchtlicher Arbeitsaufwand für das System bedeutet. Alles in allem wird somit eine Auslastung des Systems erzeugt, die im echten Einsatz nie auftreten sollte. Nach der Theorie dürften sich dadurch aber die Echtzeitprogramme eines Echtzeitbetriebssystemes nicht aus der Ruhe bringen lassen.
Die ermittelten Benchmarks sind nur für die spezifischen Hardware-Boards gültig, zeigen jedoch eine Tendenz für das qualitative Verhalten der einzelnen Echtzeitsysteme. Der prioritätsbasierte Scheduler funktioniert bei allen getesteten Kombinationen; jeder Thread wurde mehrmals von den höher priorisierten Threads unterbrochen. Lediglich auf der PowerPC-Hardware gab es Messfehler, die auf prellende Hardware-Ausgänge zurückzuführen waren.

RTAI: Probleme bei Überlast

Interessant ist das Verhalten der Systeme bei Überlast: Während die Xenomai-Lösungen und der Rt-Preempt gepatchte Kernel die durch Echtzeit-Threads produzierte Überlast problemlos verkraften, frieren die RTAI-Kombinationen das System unwiderruflich ein.
Die Interrupt-Latenz-Messungen auf x86-Systemen ergibt bei RTAI eine Interrupt-Latenz von 9 µs. Ohne CPU-Last gibt es hier keine Ausreiser. Die Reaktionszeit von Xenomai ist sowohl im Leerlauf als auch unter hoher CPU-Last bei 11 µs angesiedelt. Allerdings zeigt es vereinzelt Ausreisser bis zu 42 µs. Da ORF im Kombination mit dem Rt-Preempt Patch im Userspace läuft und sich im Userspace Interrupts nicht ohne weiteres verarbeiten lassen, ist die Messung für diese Kombination nicht durchgeführt worden.
Bei der Jitter-Messung schneidet RTAI tendenziell besser ab als Xenomai und der Rt-Preempt Patch. Auf Intel-Plattformen erreichte RTAI mit beiden Kernel-Versionen einen Worst-Case-Jitter von 1 µs bei Leerlauf und 5-17 µs unter Last. Xenomai/Linux-2.6 bleibt mit 61 µs im Leerlauf und 75 µs unter Last weit hinter den RTAI-Kombinationen. Der Rt-Preempt patch liegt mit einem Worst-Case Jitter von 30,3 µs zwischen RTAI und Xenomai.
Aufgrund der deutlich geringeren Taktfrequenzen haben PowerPCs in allen Kombinationen schlechtere absolute Werte: Der Jitter von RTAI/Linux-2.4 liegt bei PowerPC bei 17,5 µs im Leerlauf und 18,7 µs unter Last. Xenomai kann auf dem PowerPC weder mit dem 2.4er- noch mit dem 2.6er-Kernel mithalten und produziert einen Jitter von 22,9 µs ohne Last und 31,8 µs unter Last.
Die Periodizität ist die Parade-Disziplin von RTAI: In Kombination mit dem Kernel 2.4 absolviert RTAI auf einer x86er-CPU 10000 Zyklen in der Sekunde ohne Fehler, gefolgt von RTAI/Linux-2.6 mit 5000 Zyklen. Xenomai erreicht hier nur 800 Zyklen in der Sekunde und der Rt-Preempt Patch reiht sich mit 1600 Zyklen wieder im Mittelfeld ein. Da dieser Benchmark direkt mit der Geschwindigkeit der Hardware zusammenhängt, sind die Ergebnisse auf dem PowerPC entsprechend schlechter.
Die Messung der Interprozesskommunikation zeigt, dass die Datenrate allein von der CPU-Performance abhängt. Auf der x86-Hardware erreichen alle Kombinationen im Leerlauf eine Datenrate von etwa 3,5 MByte/s, die mit ansteigender Last auf 0,5 MByte/s abnimmt.
Die Evaluierungen zeigen, dass für alle Hardware-Architekturen funktionierende Echtzeiterweiterungen für embedded Linux existieren. Bei identischer Hardware liefert RTAI in den meisten Fällen die besseren Werte bezüglich Jitter und Latentzzeit als Xenomai. Allerdings rückt die Tatsache, dass RTAI bei einer Überlast durch Echtzeitanwendungen das System einfrieren lässt, die Ergebnisse von Xenomai in ein besseres Licht.
Der Realtime Preemption Patch liefert zwar teilweise schlechtere Werte beim harten Echtzeitverhalten, hat aber durch seine Integration in den Mainline-Kernel von Linux Vorteile bezüglich Wartung und Systemintegration.