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.

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 (siehe Kasten „Die konzeptionellen Unterschiede“).

RTAI wurde als einer der ersten Echtzeit-Ansä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, seit 2005 aber wieder separat weiterentwickelt. Der RT-Preempt-Patch wird in Deutschland von der OSADL (Open Source Automation Development Lab) vorangetrieben mit dem Ziel, ihn schließlich komplett in den Mainline-Kernel von Linux zu integrieren.

Die Testumgebung basiert auf dem Open Realtime Framework (ORF), einer standardisierten API für Echtzeit-Anwendungen, 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ätsbasierten Schedulers,
  • Verhalten bei Überlast,
  • Taskwechsel-Frequenz
  • sowie 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 Echtzeit-Systemen. 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 Echtzeit-System, 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, Echtzeit-Funktionalität wird ü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.