Ein Angebot von

Echtzeit mit Linux

| Autor / Redakteur: Jan Altenberg und Heinz Egger* / Sebastian Gerstl

Auch unter Linux sind - unter den richtigen Voraussetzungen - harte Echtzeitanforderungen erfüllbar.
Auch unter Linux sind - unter den richtigen Voraussetzungen - harte Echtzeitanforderungen erfüllbar. (Bild: gemeinfrei / Pixabay)

Mit Linux können Systeme mit harten Echtzeit-Anforderungen einfach umgesetzt werden. Doch welcher Ansatz ist der richtige? Und welche Latenzzeiten können damit erreicht werden?

Linux ist aufgrund der hohen Anzahl unterstützter CPU Architekturen, der nahezu unendlichen Anzahl von Treibern und der guten Portierbarkeit und Skalierbarkeit eines der leistungsfähigsten Embedded Betriebssysteme unserer Zeit. Auch Systeme mit Anforderungen an harte Echtzeit können mit Linux einfach umgesetzt werden.

Für Echtzeit mit Linux gibt es unterschiedliche Varianten und Ansätze. Doch welcher Ansatz ist der richtige? Und welche Latenzzeiten können damit erreicht werden? Dieser Artikel stellt unterschiedliche Technologien vor, mit denen harte Echtzeitfähigkeit unter Linux erreicht werden kann. Weiterhin wird aufgezeigt, welcher Jitter und welche Latenzzeiten mit diesen Technologien erreicht werden können.

Verfügbare Technologien für Echtzeit-Linux

Grundsätzlich gibt es zwei Ansätze, um Linux echtzeitfähig zu machen: Mikrokernel-Ansatz und In-Kernel Ansatz. Im Mikrokernel Ansatz werden alle Echtzeitaufgaben in einem eigenen RTOS gehandhabt, Linux wird innerhalb dieses RTOS als niederpriore Task geschedult. Genaugenommen muss hier also nicht von Echtzeit mit Linux, sondern vielmehr von Echtzeit neben Linux gesprochen werden. Der sogenannte In-Kernel Ansatz verfolgt das Ziel, Linux an sich echtzeitfähig zu machen (ohne darunterliegenden Mikrokernel). Im Folgenden sollen verschiedene Vertreter dieser Ansätze vorgestellt werden.

RTAI: Realtime Application Interface

Das Realtime Application Interface (RTAI) ist eine Entwicklung der Technischen Universität Mailand und entstand unter der Schirmherrschaft von Professor Paolo Mantegazza. RTAI ist ein klassischer Vertreter des Mikrokernel Ansatzes. Oberstes Designziel von RTAI ist und war es, die kleinstmöglichen Latenzzeiten auf einer gegebenen Hardwareplattform zu erzielen. Dieses Designziel bedingt diverse Ein-schränkungen für RTAI Applikationen. Weiterhin wird nur eine recht kleine Anzahl an Zielplattformen unterstützt (derzeit x86, x86_64 und diverse ARM Plattformen). In der Praxis finden sich kaum noch neue Projekte, die auf RTAI aufsetzen. Bild 1 in der Bildergalerie zeigt den prinzipiellen Aufbau von RTAI.

Xenomai: Echtzeit im Userpace einfach nutzen

Das Xenomai Projekt wurde im Jahre 2001 gegründet. Im Gegensatz zu RTAI erlaubt es Xenomai Echtzeit im Userpace relativ einfach zu nutzen (RTAI erlaubt dies nur sehr eingeschränkt). Die Besonderheit von Xenomai sind die sogenannten Skins, die es vereinfachen sollen, Applikationen von anderen Echtzeitsystemen (z. Bsp. VxWORKS, …) nach Xenomai zu portieren.

Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit folgende Architekturen: PowerPC32, PowerPC64, x86, x86_64, Blackfin, ARM und ia64). Die zentralen Begriffe im Designkonzept von Xenomai stellen Xenomai Nucleus, die Interrupt Pipeline (IPIPE), Hardware Abstraction Layer (HAL) und System Abstraction Layer (SAL) dar. Die IPIPE kann bildlich als virtueller Interruptcontroller betrachtet werden. Sie organisiert das System in verschiedene Domains. Interrupts werden von IPIPE entgegengenommen und an die einzelnen Domains verteilt.

Nucleus beinhaltet die Xenomai-Core-Funktionalität. Diese ist zuständig dafür, alle notwendigen Ressourcen bereitzustellen, die Skins benötigen um die Funktionalität von RTOS-en nachbilden zu können. Der Hardware Abstraction Layer beinhaltet den Plattform und CPU abhängigen Code. Alle darüber liegenden Layer (darunter auch Nucleus) bauen darauf auf. Sowohl im Kernel als auch in der Applikation muss mit eigenen Bibliotheken und einer eigenen API gearbeitet werden. Es können also nicht die Standard Linux Bibliotheken verwendet werden! (dies gilt auch für RTAI). Bild 2 in der Bildergalerie zeigt das Konzept von Xenomai.

Der Linux Echtzeit-Preemption-Patch PREEMPT_RT

Der Realtime Preemption Patch entstand ursprünglich aus Arbeiten von Ingo Molnar und Thomas Gleixner. Vor allem Thomas Gleixner ist heute die treibende Kraft bei der Entwicklung von PREEMPT_RT. Im Gegensatz zu RTAI und Xenomai macht PREEMPT_RT den Linux Kernel an sich echtzeitfähig. Dies wird im Besonderen durch folgende Mechanismen erreicht:

  • Sleeping Spinlocks: Spinlocks werden durch RT Mutexe ersetzt. Raw Spinlocks ersetzen die Eigenschaft der ursprünglichen Spinlocks
  • Threaded Interrupt Handlers: Interrupt Handler laufen per Default nicht im harten Interruptkontext, sondern als Kernelthread.

Viele Mechanismen, die ursprünglich in PREEMPT_RT entwickelt wurden, haben schon lange Ihren Weg in den Mainline Linuxzweig gefunden: High Resolution Timer (Hochauflösende Timer unabhängig vom Scheduler Tick), Priority Inheritance, generisches Interrupthandling für alle Architekturen und bereits in 2.6.30 die Threaded Interrupt Handler.

Weiterhin hat sich die Linux-Entwicklergemeinde schon im Jahre 2006 darauf geeinigt, dass Preempt RT in den Linux Kernel integriert wird. Mit den Arbeiten des OSADL und einer neuen Working Group der Linux Foundation (RTL, gegründet Oktober 2015; Gründungsmitglieder sind u.a. Google, OSADL, Intel, ARM, Texas Instruments, Altera, National Instruments u.a.) wurde erst kürzlich ein weiterer großer Schritt in diese Richtung getan. Aufgrund der vielen Vorteile und der großen Akzeptanz in der Linux Community hat sich PREEMPT_RT in den letzten Jahren als de-facto Standard für Echtzeitlinux durchgesetzt.

Neben den vielen technologie-bedingten Vorteilen ist noch die Tatsache erwähnenswert, dass sich das OSADL in umfangreichem Maße mit der Qualitätssicherung für PREEMPT_RT basierte Systeme befasst. Hierfür werden in einer Testfarm unzählige Benchmarks und Latenzzeitmessungen auf einer Vielzahl von Hardware durchgeführt (https://www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html).

Weiterhin bietet der Realtime Preemption Patch den großen Vorteil, dass Echtzeitapplikationen als POSIX Realtime Applikationen geschrieben werden können. Es wird keine spezielle API verwendet. PREEMPT_RT Unterstützt eine Vielzahl von Architekturen (PowerPc, x86, x86_64, MIPS, ARM, ...).

Bild 3: Struktur von Preempt_RT
Bild 3: Struktur von Preempt_RT (Bild: linutronix GmbH)

Wie Bild 3 zeigt, integriert PREEMPT_RT die Echtzeitfunktionalität ''nahtlos'' in den Linux Kernel. Auch die Entwickler anderer Projekte haben die Vorzüge von PREEMPT_RT bereits erkannt. Xenomai 3 bietet Unterstützung für PREEMPT_RT. Dies ermöglicht den Einsatz von Xenomai Skins auf PREEMPT_RT Kerneln.

Evaluierung der unterschiedlichen Ansätze für Echtzeit-Linux

Zur Gegenüberstellung von Mikro-Kernel und In-Kernel Ansätzen wurden vergleichende Messungen auf einer ARM Cortex A9 CPU durchgeführt. Xenomai wurde als Vertreter der Mikro-Kernel Technologie gewählt, PREEMPT_RT als Vertreter der In-Kernel Technologie. Gemessen wurde die Reaktionszeit auf ein externes Signal, welches mit einer Frequenz von 10kHz generiert wurde.

Zur Durchführung der Messungen wurde die OSADL Latency Box verwendet. Gemessen wurde jeweils die Reaktionszeit für Kernel und Applikation. Alle Messungen wurden unter denselben Bedingungen und 100% CPU Last durchgeführt (erzeugt mit dem Programm „hackbench“).

Embedded-Linux-Woche: Programm und Anmeldung Auf der Embedded-Linux-Woche in Würzburg können Sie Ihr Wissen weiter vertiefen. Prämierte Referenten geben dort Seminare für Einsteiger, Fortgeschrittene und Experten zu verschiedenen Themen der Embedded Linux-Programmierung. Mehr Informationen zu Kursen und Anmeldung finden Sie auf www.linux4embedded.de.

Ergebnisse Xenomai

Bild 4 in der Bildergalerie zeigt die Reaktionszeit auf das Event im Kernel. Bild 5 stellt die Latenzzeiten für eine Applikation dar, die auf das Event wartet. Der Worst-Case liegt bei knapp unter 100 Mikrosekunden.

Ergebnisse PREEMPT_RT

Bild 6 + 7 in der Bildergalerie zeigen die Reaktionszeiten im Kernel unter PREEMPT_RT. Durch Isolieren eines Cores lässt sich der Worst-Case noch etwas verbessern.

Bei den Messungen für die Applikation schneidet PREEMPT_RT etwas besser ab als Xenomai. Der Worst-Case liegt bei etwas über 90 Mikrosekunden.

Bild 10: FIQ basierte Lösung auf PREEMPT_RT
Bild 10: FIQ basierte Lösung auf PREEMPT_RT (Bild: linutronix GmbH)

Durch Isolieren eines Cores lässt sich das Ergebnis auf 80 Mikrosekunden verbessern: Nun ist der Vergleich der Reaktionszeiten im Kernel nicht ganz fair, denn bei Xenomai sprechen wir hier ja von einem Mikrokernel und nicht vom Linux Kernel. Denn genaugenommen arbeiten wir den Code ja nicht im Linux Kontext ab (wie es bei Xenomai der Fall ist). Daher wurde für PREEMPT_RT noch eine weitere Messung durchgeführt: Das Abarbeiten des kritischen Codepfades im FIQ Kontext (den viele ARM basierte SOCs bieten). Der FIQ lebt in seiner „eigenen Welt“, es ist aber möglich einen FIQ Handler aus Linux heraus zu registrieren!

Bild 10 zeigt die Ergebnisse einer FIQ basierten Lösung (basierend auf einem PREEMPT_RT Kernel). Der Worst-Case ließ sich hier auf 30 Mikrosekunden verbessern! Dieser einzelne „Ausreißer“ lässt sich mit großer Wahrscheinlichkeit auf ein Hardwareproblem zurückführen. Auf anderen Plattformen konnten mit diesem Ansatz Reaktionszeiten von < 10 Mikrosekunden erreicht werden!

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben
1. Echtzeit bedeutet vor allem beweisbares deterministisches Verhalten und nicht nur kleine...  lesen
posted am 06.02.2019 um 09:13 von Unregistriert


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44317182 / Echtzeit)