Clever Geek Handbook

Linux in Echtzeit



Ein Echtzeitbetriebssystem wird benötigt, wenn Zeitanforderungen an den Prozessor oder den Datenfluss gestellt werden. Daher spielt es in speziellen Geräten häufig die Rolle einer Steuereinheit. Wissenschaftliche Experimente, Visualisierungsanwendungen in der Medizin und industrielle Steuergeräte sind Echtzeitsysteme. Kraftstoffeinspritzmechanismen von Kraftfahrzeugmotoren, Steuerungen für Haushalts- und Militärausrüstungen sind ebenfalls Echtzeitsysteme.



Darüber hinaus haben unterschiedliche Ereignisse unterschiedliche Zeitanforderungen. Beispielsweise kann die Latenzzeit für ein Antiblockiersystem zwischen 3 und 5 Millisekunden liegen. Das heißt, ab dem Moment, an dem das Rad zum ersten Mal feststellt, dass es durchrutscht, hat das System, das die Antiblockierbremsen steuert, 3-5 Millisekunden Zeit, um zu reagieren und die Situation zu korrigieren.



Echtzeit-Kernel-Funktionen gibt es im Open-Source-Ökosystem seit über einem Jahrzehnt. Die Red Hat Enterprise Linux (RHEL) -Unterstützung für den Echtzeitkernel war für dieselbe Zeit verfügbar. Viele Systemadministratoren interpretieren jedoch die Grundkonzepte und das tatsächliche Betriebsverhalten falsch. In diesem Artikel werde ich einige seiner Hauptfunktionen, Unterschiede zum Standardkernel und Installationsschritte beschreiben.



Echtzeit-CPU-Scheduler



Für verschiedene Problemklassen kann man weiche Echtzeitsysteme und harte Echtzeitsysteme bezeichnen . Ersteres garantiert nicht den genauen Zeitpunkt, zu dem der kritische Prozess in Echtzeit geplant wird. Sie garantieren nur, dass der Prozess gegenüber unkritischen Prozessen bevorzugt wird. Letztere haben strengere Anforderungen und die Aufgabe wird entweder innerhalb des angegebenen Zeitrahmens abgeschlossen oder als nicht erledigt betrachtet.



Wir nennen Ereignisverzögerung die Zeit, die vom Eintreten des Ereignisses bis zum Zeitpunkt seiner Wartung vergeht. Es gibt zwei Arten von Verzögerungen, die sich auf die Leistung des Echtzeitbetriebssystems auswirken.



  • CPU . , . , interrupt service routine (ISR).





    . 1 .
  • , , . , . .





    . 2 .






Das wichtigste Merkmal eines Echtzeitbetriebssystems besteht darin, sofort auf einen kritischen Prozess zu reagieren, der Zugriff auf CPU-Ressourcen erfordert. Infolgedessen muss der Scheduler für das Echtzeitbetriebssystem den präemptiven Interrupt-Algorithmus unterstützen. Diese Algorithmen weisen jedem Prozess basierend auf seinem Wichtigkeitsgrad Priorität zu. Wenn der Scheduler auch Preemption unterstützt, wird der aktuelle Prozess auf der CPU bei Bedarf zugunsten eines Prozesses mit höherer Priorität vorbelegt.





Zahl: 3 Klassifizierung der Planer.



Es gibt verschiedene Algorithmen für den Echtzeitplaner.



  • Rate-Monotonic Scheduling — . , . .





    n, ln2 ≈ 0.693147.
  • Earliest-deadline-first (EDF) Scheduling . , , . RMS, EDF , . , , .





    . 4 EDF.



    . 4 T1 T2 , T2. T3 T1, 23.
  • POSIX real-time-scheduling. POSIX.4 . , .



    • SCHED_FIFO — , « — » (FIFO). 32 .
    • SCHED_RR — SCHED_FIFO, ( ) . 32 .
    • SCHED_OTHER — ; - .




Installation und Verwendung von RHEL Real Time



Zunächst müssen Sie das Red Hat Enterprise Linux-Echtzeit-Repository verbinden und die RT-Paketgruppe installieren. 



[root@server ~]# subscription-manager repos --enable rhel-8-for-x86_64-rt-rpms
[root@server ~]# yum groupinstall RT


RT enthält folgende Komponenten:



  • kernel-rt - Kernel mit Echtzeitfunktionalität;
  • RT-Setup - Installation der Red Hat Enterprise Linux-Echtzeitumgebung;
  • RT -Tests - Dienstprogramme zum Testen von RT-Funktionen;
  • rt-eval - um die Möglichkeit der Verwendung von RT auf einem bestimmten System zu bewerten;


Stellen Sie nach der Installation von RT und dem Neustart sicher, dass der Kernel-RT geladen ist. 



[root@server ~]# uname -a
Linux rt-server.example.com 4.18.0-80.rt9.138.el8.x86_64 …


Schauen wir uns einige der Unterschiede zwischen Kernel-RT und dem Standard-Kernel an.



  • Bei hoher Last wird die Aufgabenpriorität überprüft (1-99).
  • Aufgaben mit hoher Priorität (99) werden beim Zugriff auf CPU-Ressourcen bevorzugt.
  • Erzwingt nicht die CFS- Richtlinie (Completely Fair Scheduling) .
  • Verwendet die Richtlinie SCHED_FIFO oder SCHED_RR .




Zahl: 5 Vergleichen von kernet_rt mit dem Standardkernel.





Die Grafik zeigt ein Beispiel für die Antwortzeit von Millionen Wiederholungen für Systeme, die den Kernel RHEL Linux 7 bzw. RHEL Real Time verwenden. Die blauen Punkte in diesem Diagramm repräsentieren die Antwortzeiten (in Mikrosekunden) von Systemen mit dem Standard-RHEL 7-Kernel, und die grünen Punkte repräsentieren die RHEL 7-Echtzeit. Aus dem Diagramm ist ersichtlich, dass das Merkmal von Kernel-RT eine viel geringere Varianz und dementsprechend eine bessere Vorhersagbarkeit der Systemantwortzeit ist.



Einrichten und Testen



Nach der Installation von RT sind möglicherweise zusätzliche Optimierungen und Optimierungen erforderlich, um die konsistentesten Systemantwortzeiten zu erzielen. Solche Anforderungen können von Unternehmen im Finanz- oder Telekommunikationssektor gestellt werden. Das Setup selbst ist ein iterativer Prozess und Sie müssen zu Beginn des Prozesses geduldig sein. Es ist unwahrscheinlich, dass es möglich sein wird, einige Variablen zu optimieren und zu verstehen, dass das bestmögliche Ergebnis erzielt wurde.



Das Dienstprogramm hwlatdetect aus dem Paket rt-tests zeigt die durch die Hardware und Firmware verursachte Latenz an, indem die Taktquelle abgefragt und nach undurchsichtigen Lücken gesucht wird. 



[root@server ~]#  hwlatdetect --duration=60s
hwlatdetect:  test duration 60 seconds
	detector: tracer
	parameters:
		Latency threshold: 10us
		Sample window:     1000000us
		Sample width:      500000us
		Non-sampling period:  500000us
		Output File:       None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0
Samples exceeding threshold: 0


In diesem Beispiel geben Parameter die Verzögerungs- und Erkennungsmethode an. Die Standardlatenzschwelle wurde auf 10 Mikrosekunden (10 μs) eingestellt.



RT verfügt außerdem über ein Dienstprogramm namens rteval zum Testen der Systemleistung in Echtzeit unter Last. Das Programm belastet das System mit dem Scheduler SCHED_OTHER stark und misst dann die Echtzeitantwort auf jeder der aktiven CPUs. Ziel ist es, verschiedene Aufgaben ständig auszuführen, z. B. Zuweisen / Freigeben von Speicher, Festplatten-E / A, Berechnung, Kopieren von Speicher und andere.



Jeder Mess-Thread nimmt einen Zeitstempel, ist für ein bestimmtes Intervall inaktiv und nimmt beim Aufwachen einen weiteren Zeitstempel. Die Messverzögerung ist gleich t1 - (t0 + i)wo



  • t1 - tatsächliche Messzeit;
  • t0 - theoretische Weckzeit des ersten Zeitstempels;
  • Ich bin das Warteintervall.


Der Bericht des Dienstprogramms rteval sieht folgendermaßen aus. 



System:
Statistics:
	Samples:           1440463955
	Mean:              4.40624790712us
	Median:            0.0us
	Mode:              4us
	Range:             54us
	Min:               2us
	Max:               56us
	Mean Absolute Dev: 1.0776661507us
	Std.dev:           1.81821060672us

CPU core 0       Priority: 95
Statistics:
	Samples:           36011847
	Mean:              5.46434910711us
	Median:            4us
	Mode:              4us
	Range:             38us
	Min:               2us
	Max:               40us
	Mean Absolute Dev: 2.13785341159us
	Std.dev:           3.50155558554us


Gebrauchte Materialien











More articles:


All Articles