Software
Echtzeit im Echtheits-Test
Fortsetzung des Artikels von Teil 1
Kernel für Echtzeit-Messaufgaben konfigurieren
Damit der Echtzeit-Linux-Kernel die genannten Histogramme enthält, muss dieser bei der Herstellung entsprechend konfiguriert werden. Dafür werden zwei Konfigurationsparameter verwendet (Kernel-Version 2.6.33.7.2-rt30):
CONFIG_WAKEUP_LATENCY_HIST=y
CONFIG_MISSED_TIMER_OFFSETS_HIST=y
Es kann durchaus empfohlen werden, den Kernel routinemäßig so zu konfigurieren; denn durch die Konfiguration allein werden die Histogramme nur bereitgestellt, aber noch nicht eingeschaltet. Wenn die Histogramme dann tatsächlich verwendet werden sollen, müssen sie zur Laufzeit aktiviert werden. Dies erfolgt durch Schreiben eines Wertes ungleich 0 in die jeweiligen virtuellen Dateien im „enable“-Verzeichnis des Debug-Filesystems debugfs:
cd /sys/kernel/debug/tracing/latency_hist
echo 1 >enable/wakeup
echo 1 >enable/missed_timer_offsets
echo 1 >enable/timerandwakeup
Aber auch nach dem Einschalten der Histogramme kommt es zu keinem relevanten Performance-Verlust, so dass die Messung auch unter Produktionsbedingungen durchgeführt werden kann. Dadurch geringfügig verlängert gemessene Latenzen würden ein eher konservatives Ergebnis liefern und wären daher sicherheitsmäßig unbedenklich.
Jobangebote+ passend zum Thema
Im jeweils gleichnamigen Unterverzeichnis findet sich pro CPU (d.h. pro Core und Hyperthread) eine Datei mit dem Namen „CPU“, gefolgt von der Nummer der CPU. Darin ist jeweils eine Zeile pro Mikrosekunde Latenz enthalten, welche die Anzahl an Messwerten der jeweiligen Latenzkategorie enthält. Am Anfang der Datei werden statistische Kennwerte der Verteilung ausgegeben wie z.B. im Listing.
Damit eine gewisse zeitliche Zuordnung einer Latenz zu einem bestimmten Zeitraum ermöglicht wird, ist eine virtuelle Reset-Datei vorgesehen. Durch Schreiben eines Wertes ungleich 0 in die entsprechende Datei werden alle Zellen des Histogramms auf Null zurückgesetzt. Der vorher ausgelesene maximale Latenzwert bezieht sich entsprechend auf den Zeitraum seit dem letzten Reset.
Applikations-Messung mit „Cyclictest“
Um die im Kernel eingebauten Histogramme empirisch überprüfen zu können, sollte eine zweite unabhängige Messmethode verfügbar sein. Diese sollte möglichst gut die Bedingungen simulieren, die auch in einem unter Produktionsbedingungen verwendeten Echtzeit-System herrschen. Im OSADL Echtzeit-Testzentrum wird das ursprünglich von Thomas Gleixner geschriebene und von der Linux-Echtzeit-Community weiterentwickelte Tool „Cyclictest“ verwendet. Es ist in den RT-Testprogrammen „RT-Tests“ enthalten, deren Maintainer Clark Williams (Red Hat) ist. Die jeweils aktuelle Version ist als Git-Tree im Internet verfügbar [1].
Nach dem Programmstart von Cyclictest wird eine bestimmte, durch Kommandozeilen-Optionen vorgegebene Anzahl an Mess-Threads gestartet, die zyklisch angehalten und mit Hilfe von Alarmen wieder gestartet werden. Nach jedem Start wird die aktuelle Uhrzeit mit der erwarteten Uhrzeit verglichen, die Differenz dem Hauptprozess verfügbar gemacht und von diesem angezeigt bzw. - je nach Kommandozeilen-Option - in einem Histogramm akkumuliert. Auch dieses Histogramm weist eine Granularität von 1 µs auf, und auch hier ist wieder nur der höchste jemals gemessene Wert relevant; aus dem Kurvenverlauf des Histogramms lassen sich aber auch wichtige Rückschlüsse auf die Stabilität der Echtzeit-Fähigkeit und auf die Ursache möglicher verlängerter Latenzen ableiten. Von der sehr großen Anzahl an Kommandozeilen-Optionen des Programms Cyclictest ist für die Routine-Messung nur eine kleine Anzahl bedeutsam. Für Single-Core- bzw. Multi-Core-Systeme werden folgende Optionen verwandt:
Single-Core-Systeme:
Mit der Kommandozeile cyclictest -l100000000 -m -a0 -t1 -n -p99 -i200 -h200 -q werden eine Gesamtzahl von 100 Millionen Messzyklen, eine Priorität von 99, ein Mess-Intervall von 200 µs und 200 Histogrammzellen mit einer Granularität von 1 µs gewählt. Die Option „-n“ führt zur notwendigen Verwendung des hochauflösenden Timers, und die Option „-m“ sorgt dafür, dass der vom Prozess verwendete Speicher niemals ausgelagert werden kann. Die gewählten 100 Millionen Messzyklen von jeweils 200 µs führen zu einer Gesamtdauer der Messung von 5 Stunden und 33 Minuten.
Multi-Core-Systeme:
Mit der Option „-S“ der Kommandozeile cyclictest -l100000000 -m -Sp99 -d0 -i200 -h200 -q wird zusätzlich symmetrisches Multiprocessing (SMP) konfiguriert. Dies führt dazu, dass genauso viele Threads gestartet werden, wie Cores vorhanden sind, und alle Threads mit der gleichen Priorität von in diesem Fall 99 laufen. Mit der Option „-d0“ wird dafür gesorgt, dass alle Threads komplett zeitgleich ablaufen, was eine besonders große Herausforderung an die Echtzeit-Fähigkeit darstellt.
- Echtzeit im Echtheits-Test
- Kernel für Echtzeit-Messaufgaben konfigurieren
- Das OSADL Echtzeit-Testzentrum
- Literatur & Autor
Das könnte Sie auch interessieren
Betriebssysteme:
Echtzeit-Performance mit 64-bit-Windows
Embedded Design
Windows-Echtzeit-Erweiterung oder DSPs – wer ist schneller?
