Linux und Echtzeit

Autoren: Jan Altenberg, Heinz Egger, Linutronix GmbH

Beitrag - Embedded Software Engineering Kongress 2015

 

Linux ist aufgrund der hohen Anzahl unterstützter CPU-Architekturen, der nahezu unendlichen Anzahl von Treibern und nicht zuletzt der guten Portierbarkeit und Skalierbarkeit eines der leistungsfähigsten Embedded-Betriebssysteme unserer Zeit. Auch Systeme mit harten Echtzeitanforderungen können mit Linux einfach umgesetzt werden. Hierfür 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

Grundsätzlich gibt es zwei Ansätze, um Linux echtzeitfähig zu machen:

• den sogenannten Mikrokernel-Ansatz und
• den sogenannten 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

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. Abbildung 1 (siehe PDF) zeigt den prinzipiellen Aufbau von RTAI.

Xenomai

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.B. 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 Biblio­theken und einer eigenen API gearbeitet werden. Es können also nicht die Standard-Linux-Bibliotheken verwendet werden! (Dies gilt auch für RTAI). Abbildung 2 (siehe PDF) zeigt das Konzept von Xenomai.

Der Realtime 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 Echtzeit-Linux durchgesetzt. Neben den vielen technologiebedingten 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 Echtzeit­applikationen 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, ...).

Wie Abbildung 3 (siehe PDF) 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

Zur Gegenüberstellung von Mikro-Kernel- und In-Kernel-Ansätzen wurden verglei­chende 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 (https://www.osadl.org/uploads/media/OSADL-Latency-Box.pdf). 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").

Ergebnisse Xenomai

Abbildung 4 (siehe PDF) zeigt die Reaktionszeit auf das Event im Kernel.

Abbildung 5 (siehe PDF) 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

Die Abbildungen 6 und 7 (siehe PDF) zeigten 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 (siehe Abbildung 8, PDF). Durch Isolieren eines Cores lässt sich das Ergebnis auf 80 Mikrosekunden verbessern (siehe Abbildung 9, PDF).

Nun ist der Vergleich der Reaktionszeiten im Kernel nicht ganz fair, denn bei Xeno­mai sprechen wir hier ja von einem Mikrokernel und nicht vom Linux-Kernel. Denn genau genommen 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.

Abbildung 10 (siehe PDF) 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 < 10us erreicht werden!

Fazit

Linux besitzt mit der passenden Erweiterung hervorragende Echtzeiteigenschaften. Aufgrund der hohen Akzeptanz in der Entwicklergemeinde und der einfachen Hand­habbarkeit hat sich hierfür der sogenannte PREEMPT_RT Ansatz als Standard etabliert. Die Latenzzeiten dieses In-Kernel-Ansatzes sind auf Applikationsebene vergleichbar mit denen von Mikrokerneln (wie Xenomai). Die Mikrokernel können lediglich im Kernel bessere Latenzen erreichen, wobei hier zu berücksichtigen ist, dass hier nicht im Linux-Kontext gearbeitet wird, sondern im Mikrokernel (und somit auch mit dessen Restriktionen und API). Wer bereit ist, für bessere Latenzzeiten Restriktionen in Kauf zu nehmen, kann auf Arm-basierten Systemen auch mit einer FIQ-Lösung und PREEMPT_RT arbeiten. Hiermit sind teilweise Latenzzeiten unter 10 Mikrosekunden zu möglich.

PREEMPT_RT bietet in Summe den besten Tradeoff aus geringen Latenzzeiten und einfacher Handhabbarkeit. Weiterhin ist zu beachten, dass Organisationen wie das OSADL die Qualität des PREEMPT_RT Ansatzes kontinuierlich prüfen. Eine weitere gute Nachricht ist die Tatsache, dass die Linux Foundation das RTL-Projekt ins Leben gerufen hat, das die Integration in den Linux-Mainlinekernel über die nächsten Jahre finanziert und vorantreibt. Diese Tatsachen geben dem Anwender zusätzliche Planungssicherheit für zukünftige Projekte und die Pflege bestehender Produkte.

 

Beitrag als PDF downloaden

 

---

Open Source - unsere Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Open Source / Embedded Software Engineering.

 

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.

---

Open Source - Fachwissen

Wertvolles Fachwissen zum Thema Open Source / Embedded Software Engineering steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.