Embedded Linux

Linux für Echtzeit-Anforderungen

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

Container halten auch in Echtzeitanwendungen Einzug. Wie sie sich verhalten, zeigen etwa die Kernel-Latenzzeiten innerhalb eines Containers.
Container halten auch in Echtzeitanwendungen Einzug. Wie sie sich verhalten, zeigen etwa die Kernel-Latenzzeiten innerhalb eines Containers. (Bild: Linutronix)

Mit Linux-Derivaten lassen sich schon seit vielen Jahren Systeme mit Echtzeit-Anforderungen aufsetzen. Doch welcher Ansatz ist heute der richtige? Und welche Latenzzeiten sind erreichbar?

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

Dieser Artikel stellt unterschiedliche Techniken vor, mit denen sich Echtzeitfähigkeit unter Linux erreichen lässt. Weiter wird aufgezeigt, welcher Jitter und welche Latenzzeiten damit erreicht werden können.

Grundsätzlich gibt es zwei Ansätze, um Linux echtzeitfähig zu machen: der Microkernel- und der In-Kernel Ansatz. Im Micro-Kernel Ansatz werden alle Echtzeitaufgaben in einem eigenen RTOS gehandhabt, Linux wird innerhalb dieses RTOS als niederpriore Task geschedult.

Genau genommen ist hier also nicht von Echtzeit mit Linux die Rede. Es sollte an dieser Stelle eher von Echtzeit neben Linux gesprochen werden. Der so genannte In-Kernel Ansatz verfolgt das Ziel, Linux an sich echtzeitfähig zu machen (ohne darunterliegenden Micro-Kernel).

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 Micro-Kernel-Ansatzes.

Ergänzendes zum Thema
 
Seminar-Tipp: Embedded-Linux-Woche

Oberstes Designziel von RTAI war es, kleinstmögliche Latenzzeiten auf einer gegebenen Hardwareplattform zu erzielen. Dieses Ziel bedingt diverse Einschränkungen für 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.

Xenomai: Echtzeit im Userpace

Das „Xenomai“-Projekt wurde 2001 gegründet. Im Gegensatz zu RTAI erlaubt es Xenomai, Echtzeit im Userpace relativ einfach zu nutzen. Die Besonderheit von Xenomai sind die so genannten Skins, die es vereinfachen sollen, Applikationen von anderen Echtzeitsystemen, zum Beispiel „Vxworks“, nach Xenomai zu portieren.

Xenomai Skins bilden die API dieser Systeme ab. Xenomai unterstützt derzeit folgende Architekturen: „Power PC32“, „Power PC64“, x86, x86_64, „Blackfin“, ARM und „ia64“). Die zentralen Begriffe im Designkonzept von Xenomai stellen Xenomai Nucleus, die Interrupt Pipeline (IPIPE), die Hardware Abstraction Layer (HAL) und die System Abstraction Layer (SAL) dar.

Die IPIPE kann bildlich als virtueller Interrupt-Controller 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 Echtzeitbetriebssystemen 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!

Der Linux Echtzeit-Preemption-Patch PREEMPT_RT

Der „Realtime Preemption Patch“ entstand 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: Handler laufen per Default nicht im harten Interrupt-Kontext, sondern als Kernel-Thread.

Viele Mechanismen, die ursprünglich in Preempt_RT entwickelt wurden, haben schon lange Ihren Weg in den Mainline-Linux-Zweig gefunden: High Resolution Timer (Hochauflösende Timer unabhängig vom Scheduler Tick), Priority Inheritance, generisches Interrupt-Handling 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 unter anderem Google, OSADL, Intel, ARM, Texas Instruments, National Instruments) 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 technikbedingten 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 Benchmarks und Latenzzeitmessungen auf einer Vielzahl von Hardware durchgeführt (www.osadl.org/QA-Farm-Realtime.qa-farm-about.0.html).

Preempt_RT integriert die Echtzeitfunktionalität „nahtlos“ in den Kernel (siehe: Abbildung 3). 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 verschiedenen 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 10 Kilohertz 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“).

Ergebnisse Xenomai: Bild 4 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: Die Abbilungen 6 und 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.

Durch Isolieren eines Core lässt sich das Ergebnis auf 80 Mikrosekunden verbessern: Nun ist der Vergleich der Reaktionszeiten im Kernel nicht ganz fair; denn bei Xenomai sprechen ist von einem Micro-Kernel und nicht vom Linux Kernel die Rede. Denn genaugenommen arbeiten wird hier der Code nicht im Linux Kontext abgearbeitet, 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 8 zeigt die Ergebnisse einer FIQ-basierten Anwendung (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!

Einsatz von Containern und Hypervisor

Bei einer Virtualisierung werden alle Ressourcen, die ein System benötigt, vom Hypervisor zur Verfügung gestellt. Nicht vorhandene Hardware oder Zugriffe auf eine Hardware aus der virtuellen Maschine heraus werden per Software nachgebildet.

Eine virtuelle Maschine ist hier immer ein Paket aus Betriebssystem und Anwendungscode, das in der virtuellen Umgebung, also im User Space, läuft. Mit Hilfe eines Emulators kann dem Paket sogar eine andere Hardware Architektur als physikalisch vorhanden vorgegaukelt werden. Den typischen Aufbau zeigt Abbildung 9.

Beim Container-Ansatz wird auf die virtuelle Maschine, das Vorgaukeln einer eigenen Hardware und eines eigenen Betriebssystems, verzichtet. Das Betriebssystem ist für alle Container identisch, alle Container teilen sich die gleiche Hardware. Die Separierung der einzelnen Container erfolgt über spezielle Funktionen des Betriebssystems (unter Linux sind dies zum Beispiel CGROUPS und Namespaces).

Das macht die Container schlank, das heißt: Sie benötigen nicht viel zusätzlichen Code zu Ihrer eigentlichen Aufgabe. Innerhalb eines Containers befindet sich die Anwendung (oft nur eine einzige, kleine Applikation) und die dafür benötigten Libs und Frameworks. Eine Nutzung von Containern entkoppelt die Applikation von der Infrastruktur und bietet damit eine Portabilität, die heute mit Cloud zentrierten Ansätzen erwartet wird. Abbildung 10 zeigt den typischen Aufbau.

Container und VM sind in der IT Welt entstanden, um die dortigen Anforderungen zu lösen. Mit der VM wurde es möglich, mehr als nur eine Applikation pro Rechner/Server laufen zu lassen. Und in dem Maße, wie eine Anwendung von einem einzigen, großen monolithischen Block zu einer Sammlung von kleinen Anwendungen wurde, stieg der Einsatz und Nutzen der Container Technologie.

Hypervisor-Einsatz und Echtzeit-Latenzzeiten

Kombiniert man diese CPUs mit einem geeigneten Hypervisor, lassen sich auch die spezifischen Anforderungen der Automatisierung damit abdecken. Mit eine der wichtigsten technischen Anforderungen an eine Steuerung ist die Echtzeitfähigkeit.

Der Open Source Realtime Hypervisor „Jailhouse“, ein Typ I Vertreter, eignet sich hervorragend. Die Echtzeitfähigkeit im Gastsystem wird nahezu nicht beeinträchtigt, der Einfluss liegt im Bereich von < 3 µsek. Jailhouse erlaubt beliebige Kombinationen von Linux, anderen Betriebssystemen, bare-metal-Applikationen und Zuordnung von CPUs zu einem Betriebssystem.

Wenn der Hypervisor nicht eingreifen muss, wie es bei Jailhouse der Fall ist, wenn das Echtzeitbetriebssystem in einer sauber konfigurierten VM läuft und damit auch auf einer oder mehreren nur dem RTOS zugeordneten CPUs, dann sollte das zu Ergebnissen führen, die nahezu optimal sind. Und in der Tat zeigen unsere Messungen, dass auf einem x86 System der Unterschied in der Latenz zwischen einem echtzeitfähigen Linux in der root cell und in der VM nur gut 1 µs beträgt (siehe: Abbildung 11).

Container-Einsatz und Echtzeit-Latenzzeiten

Bleibt die Frage, ob Container die Echtzeit und die Performance Anforderungen industrieller Anwendungen erfüllen können. Die Abbildungen 14 und 15 zeigen, dass der Unterschied im Echtzeitverhalten einer Anwendung zwischen einer Ausführung nativ auf dem Betriebssystem und der im Container praktisch vernachlässigbar ist.

Alle Messungen wurden bei 100 Prozent CPU Last innerhalb und außerhalb der Container durchgeführt. Hierzu wurde, wie bei den vorhergehenden Messungen, das Tool hackbench eingesetzt. Ebenso wurden die Netzwerkschnitstelle sowie weitere Schnittstellen (CAN, Disk) mit voller Last beaufschlagt.

Leistungsmerkmale wie CPU Pinning bleiben auch mit Containern verfügbar. Und ein „falsch“ konfigurierter Container (beispielsweise eine Limitierung der maximalen CPU Last) hat keine Auswirkungen auf das Verhalten der RT Task.

Fazit: Hervorragende Echtzeit-Eigenschaften mit Linux

Linux besitzt mit der passenden Erweiterung hervorragende Echtzeiteigenschaften. Aufgrund der hohen Akzeptanz in der Entwicklergemeinde und der einfachen Handhabbarkeit hat sich hierfür der so genannte Preempt_RT Ansatz als Standard etabliert.

Heinz Egger
Heinz Egger (Bild: Linutronix)

Die Latenzzeiten dieses In-Kernel Ansatzes sind auf Applikationsebene vergleichbar mit denen von Micro-Kernel (wie Xenomai). Die Micro-Kernel können lediglich im Kernel bessere Latenzen erreichen, wobei hier zu berücksichtigen ist, dass hier nicht im Linux Kontext gearbeitet wird, sondern im Micro-Kernel (und somit auch mit dessen Restriktionen und API).

Jan Altenberg
Jan Altenberg (Bild: Linutronix)

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 Mainline-Kernel ü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.

Hinweis: DataCenter-Insider hat den Artikel vom Partnerportal „Embedded-Software Engineer“ übernommen.

* Jan Altenberg ist Consultant, Trainer und Projektleiter bei der Linutronix GmbH. Heinz Egger ist Geschäftsführer der Linutronix GmbH in Uhldingen-Mühlhofen.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

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