Dipl. Phys. Helmut Weber





Achtung:

Alle Beiträge sind Copyright (C) 2018 Dipl. Phys. Helmut Weber

Jedes Kopieren - egal, in welcher Form - bedarf der schriftlichen Erlaubnis.



Beispiel 3



Linux preempt_RT als Echzeitsystem



Hintergrund:

In vielen Fällen wäre es aus verschiedensten Gründen sinnvoll, ein Linux als Betriebssystem für ein embedded system zu benutzen.

Der Raspberry Pi3 verfügt bereits über WLAN, Bluetooth und viele IO-Pins.


Aber ein normales Linux ist nicht als ein RTOS-Betriebssystem anzusehen.


Das normale Linux erlaubt für einzelne Threads keine Vorherseharkeit der Ausführung, da Linux die Ausführungszeiten selbst bestimmt und damit unvorhersehbare Verzögerungen herstellt, die deterministische zeitliche Aussagen unmöglich machen.


DIN 44300

Echtzeitbetrieb ist ein Betrieb eines Rechensystems, bei dem

Programme zur Verarbeitung anfallender Daten ständig derart

betriebsbereit sind, daß die Verarbeitungsergebnisse innerhalb einer

vorgegebenen Zeitspanne verfügbar sind.


Mit dem preempt_RT Patch wird versucht, diesem Ziel näher zu kommen.


Der „cyclictest“ ist das von der OSADL-Organisation benutzte offizielle Instrument für den Test von Linux preempt_RT

zur Eignung als RTOS-System.


Hier der OSADL-Test für einen Raspberry Pi3:

OSADL1

Quelle:

https://www.osadl.org/Latency-plot-of-system-in-rack-b-slot.qa-latencyplot-rbs4.0.html?latencies=&showno=&shadow=0&slider=515

Allerdings lief dieser Test unter:   Linux 3.18.43-rt46



Hierzu habe ich zwei Linux preempt_RT Versionen  per RT-Patch hergestellt. Und zwar für:

1) Raspberry Pi 3

2) Lenovo Thinkpad W520

und "cyclictest" laufen lassen;


Raspberry PI3
Linux raspberrypi 4.14.66-rt40-v7
SMP PREEMPT RT

CPU 1,2:
Freigestellt mit ISOLCPUS


(C) 2018 H. Weber

  Bild6

(Achtung: Ich habe in späteren Test das viel neuere 4.14.74-rt44-v7 benutzt)



und


ThinkPad W420
Linux ThinkPad-W520 4.4.0-128-lowlatency
Ubuntu SMP PREEMPT x86_64
 
CPU 7
Freigestellt mit ISOLCPUS

(C) 2018 H. Weber


Bild7

Mit diesen Ergebnissen scheint Linux_preempt_RT die geforderten Echtzeit-Eigenschaften zu haben.

Es muss in beiden Fällen mit Latenzen von etwa 50 µs gerechnet werden.

Genauer:

Ein ähnlich wie CyclicTest gestaltetes Programm sollte für nicht mehr als 50µs willkürlich unterbrochen werden.

Aber: Diese Zahlen sind bei einem so komplexen System wie Linux nicht beweisbar.

Man behilft sich mit Test, die über Stunden oder Tag, Monate laufen, um so die maximalen Verzögerungen herauszufinden.

Die OSADL verwendet viel Zeit und Geld, um Linux preempt_RT als Echtzeit-Betriebssystem zu testen:


OSADL Testfarm für Linux preempt_RT System


Hier meine eigenen Tests:

 Es wurde ein Testszenario programmiert.

  Raspberry Pi 3

  CPU 1,2 wurden freigestellt (ISOLCPUS=1,2)

  Das Testprogramm lief auf diesen beiden CPUs !

  Ein Task ist zuständig für die Initialisierung und die Ausgabe der Textzeilen ( per SSH, WLAN)

  Ein zweiter Task ist für den CoopOS Scheduler reserviert, der als REALTIME-Task gestartet wird.

  Dieser zweite Task ruft seinerseit CoopOS-Tasks auf, die zeitgesteuert aufgerufen werden ( taskDelay(1000000 NANOSEKUNDEN)  =1ms).



 


Aufgabe:

Mehrere Tasks werden unabhängig voneinander jeweils im Abstand von genau einer Millisekunde gestartet. Mit welcher Genauigkeit und mit welchen maximalen Latenzen ist zu rechnen?

Wie verändern sich die Ergebnisse, wenn weitere Tasks dazukommen?


Lösung:


Es laufen 4 CoopOS-Tasks. Jeder CoopOS-Task wird je 1ms angestossen – also 4000 CoopOS-Task-Calls pro Sekunde.

Ziel ist es, jeden CoopOS-Task jeweils mit möglichst genau 1000µs Abstand zu starten.

Die Tasks optimieren selbst den Offset ihrer Aufrufe.

Aber die Tasks laufen unter Linux!

Das Besondere: Die Programme sind vollständig Hardware-unabhängig, lassen sich also für einen Microcontroller genauso wie für einen Großrechner ohne Änderung compilieren!

Für Linux ist der Preempt-Patch Voraussetzung .

Daher ist die Fragestellung:

Wie weit ist es möglich, unter Linux diese Prämisse durchzusetzen?

Ist es möglich, damit echte deterministische Verhältnisse zu schaffen, wie man sie von einem echten Realtime-System erwartet?



Wie steht es mit der Präzision der Ausführung in einem multitasking OS wie Linux, wenn die Ergbnisse auch noch per WLAN übertragen werden ?

Es werden keine Interrupts benötigt!

Das verwendete CoopOS ist den „croutine“ von freeRTOS vergleichbar, nur viel schneller!



Raspberry Pi 3:

Headless, Verbindung über WLAN, SSH

4 CoopOS-Tasks gestartet.

Ausgaben per WLAN


Nach jeweils 19 Millionen Taskaufrufe - 4 pro Millisekunde - ergibt sich folgendes Bild;
Die meisten Aufrufe geschehen mit einer Genauigkeit von wenigen Mikrosekunden,
Aber es gibt - bedingt durch Linux - Verzögerungen bis zu 22 µs.

Hier das Histogramm:
4 Tasks:

Plot


10 Tasks:

Plo1


Ein Versuch mit 20 Tasks lief über fast 5 Stunden: (neue Linuxversion 4.14.74)

20 Tasks


Plot9


Zum Vergleich: Der TinkPad W520 schaffte 20 Tasks mit einem maximalen Delay von 20µs.


Zusammenfassung

Auf dem Raspberry Pi3 mit einem Linux preempt_RT liefen 10 Tasks auf einer isolierten CPU. Jeder Tasks wurde einmal pro Millisekunde aufgerufen. Die maximale Verzögerung betrug dabei maximal (alle paar Millionen Aufrufe) 28µs, d.h. der Abstand von Aufruf zu Aufruf betrug dann statt 1000µs 1028 µs.
Für 20 Tasks: 41µs

Die Tasks machten Ausgaben über printf!


Die anderen 3 CPUs waren für Linux reserviert. Sie sorgten für den Transport der Ausgaben über SSH -> WLAN.
Es konnten z. Bsp. Programme im Hintergrund compiliert werden, oder vom im Hintergrund laufenden apache2-Webserver Seiten abgerufen werden, ohne die Echtzeit-Tasks zu beeinflussen.
Die mit CyclicTest ermittelten Ergebnisse spiegelten sich in den Tests wieder.

20 parallele Tasks
Jeder Task läuft 1000 mal pro Sekunde = 20000 Taskswitches/Sekunde
Jeder Task wird (nur in extrem seltenen Fällen!) um maximal weniger  als 50µ verzögert.




Der Raspberry Pi3 zeigt sich damit in dieser Konstellation

(Linux preemptRT + CoopOS) den meisten Systemen mit z.Bsp. einem RTOS

weit überlegen, denn Linux bietete einfach sehr viel mehr Möglichkeiten.




Nachtrag:
Es gibt inzwischen einen recht brauchbaren freeRTOS-Simulator für Linux. Unter einer isolierten CPU brachte dieser Simulator  - im Rahmen der Möglichkeiten eines RTOS - recht
überzeugende Ergebnisse. Der Takt wurde dabei auf 100µs eingestellt. Für manche embedded systems könnte auch dies eine brauchbare Alternative zu einem reinen RTOS
darstellen. Weitere Tests dazu werden folgen.
.