Dies ist eine alte Version des Dokuments!
Cyclictest startet mehrere Tasks, welche periodisch aufgerufen werden. Die effektive Periodendauer wird gemessen und der Jitter wird angezeigt.
Ein Vortrag von der „Embedded Linux Conference 2013“ bietet einen guten Einstig für die Benutzung des Cyclictest. Der Vortrag kann auf Youtube angeschaut werden. Die PPT Folien stehen hier zum Download bereit.
Siehe Projektwebseite#Installation
Bei der Copmpile-Fehlermeldung „src/cyclictest/rt_numa.h:23:18: fatal error: numa.h: No such file or directory“ siehe Projektwebseite
git clone git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
Oder bereits angepasstest Repository verwenden und anschliessend bei Punkt 7 (Build ausführen) weiterfahren.
git clone https://github.com/MarcelGehrig/rt-tests
cd rt-test
#ifdef __powerpc #define __NR_sched_setattr 355 #define __NR_sched_getattr 356 #endif
#ifndef SCHED_IDLE #define SCHED_IDLE 5 #endif
make all ARCH=powerpc CROSS_COMPILE=<pfad_zur_toolchain>powerpc-buildroot-linux-uclibc- NUMA=0
sudo ./cyclictest -p 80 -t5 -n
Erzeugt 5 Threads mit höchster Priorität von -80 (-p) mit der Verwendung von nano_sleep() (-n). Genauere Informationen siehe Projektwebseite#Run_it
Das Histogramm zeigt auf, welche Latenzen wie oft auftreten. Mit folgendem Befehl speichert der Cycletest die Daten in Form von einem Histogram ab.
sudo ./cyclictest -n -p80 -l600000 -i1000 -h1000 -q > histogramm.log
-n | use clock_nanosleep |
-p80 | Priorität -80 (Realtime) |
-l600000 | 600'000 Zyklen |
-i1000 | 1000us pro Zyklus |
-h1000 | maximal Latenzen bis 1000us werden im Histogramm gemessen |
-q | quiet: keine Ausgaben während Messung |
Messdauer: | l600000*i1000 = 600e6us = 600s = 10min |
---|
Alle Messungen die länger dauern als -h1000
erscheinen nicht im Histogramm. Diese Messungen werden gezählt und am Schluss des Logfiles als Histogram Overflows: angezeigt. Die Maximale Latenz wird als Max Latencies: angezeigt.
Um das Histogramm zu plotten kann das Matlab Skript plotHistogramm.m verwendet werden.
Grundsätzlich empfiehlt sich für RT Anwendungen eine hohe Priorität. Wenn die maximale Latenz für eine Anwendung gemessen werden soll, dann sollte die Priorität um eins höher gewählt werden, als die Priorität der zu testenden Anwendung oder Prozess.
Eine Priorität von -80 ist für RT-Prozesse mit hoher Priorität gut geeignet.
Wenn eine Priorität von -49 oder kleiner gewählt wird, wird der Cyclictest von Kerneltasks und Interrupthandler unterbrochen. Dies kann gewollt sein, wenn die RT-Anwendung diese Tasks und Interrupthandler nicht unterbrechen darf.
Eine SSH Verbindung kann notwendig sein, um eine Messung auf einem Target überhaupt starten zu können. Allerdings kann eine solche Verbindung auch einen Einfluss auf die Latenz haben. Insbesondere wenn die Priorität kleiner als 50 gewählt wurde kann das Öffnen einer neuen SSH Verbindung die maximale Latenz erhöhen.
Wenn der Test läuft, werden die aktuellsten Daten mit einer hohen Aktualisierungsrate zum Client geschickt. Um dies zu verhindern kann der Cyclictest mit der Option -q
für quiet gestartet werden. Dann werden die Messdaten erst übermittelt, wenn die Messung abgeschlossen ist, oder abgebrochen wird.
Für einen zyklischen Task mit einem Intervall von 1000us und der Priorität -80 ist ein Jitter von maximal 100-150us zu erwarten. Diese Ergebnisse können schlechter ausfallen, wenn zusätzliche Prozesse mit hoher Priorität (z.B. Interrupt Prozesse) laufen.
./cyclictest -n -p80 -t1 -i1000
In einem Blogpost schriebt Wolfgang Grandegger von ähnlichen Ergebnissen. Messungen innerhalb der NTB haben die Resultate bestätigt.
Alexander Bauer zeigt in seinem Paper Realtime capabilities of low-end PowerPC and ARM boards for embedded systems sogar noch bessere Ergebnisse auf. Laut diesem Paper ist der maximale Jitter gerade mal 45us. Allerdings wird nicht genau beschrieben, wie die Messung gemacht wurde. Solche Ergebnisse konnten in der NTB auch nicht reproduziert werden.
# ./cyclictest -p 80 -t5 -n
15h 45min lange Messung
./cyclictest -p 80 -t5 -n
3 min lange Messung
Der Cache Calibrator belastet den Cache stark. Trotz dieser Belastung ist die maximale Latenz kaum gestiegen.
dd if=/dev/zero of=/dev/null
./cyclictest -p 80 -t5 -n
27 min lange Messung
T: 0 ( 695) P:80 I:1000 C:1643188 Min: 23 Act: 65 Avg: 49 Max: 120 T: 1 ( 696) P:80 I:1500 C:1095459 Min: 24 Act: 61 Avg: 51 Max: 119 T: 2 ( 697) P:80 I:2000 C: 821594 Min: 33 Act: 47 Avg: 43 Max: 89 T: 3 ( 698) P:80 I:2500 C: 657275 Min: 28 Act: 41 Avg: 51 Max: 99 T: 4 ( 699) P:80 I:3000 C: 547729 Min: 28 Act: 44 Avg: 51 Max: 114
Dank der hohen Priorität des Cyclictest von -80 wird er vom dd-Prozess, der eine Priorität von +20 hat, nicht beeinflusst.
Für folgende Tests wurde ein Laptop mit folgenden Kenndaten verwendet:
Linux Mint 17.3 Rosa wird mit einem 3.19 Kernel ausgeliefert. Für den 3.19 Kernel existiert aber kein RT-Patch. Für die RT-Tests wurde deshalb ein 3.18 Kernel verwendet. Mit dem 3.18 Kernel funktionierte das System aber nicht mehr einwandfrei. Es konnte zum Beispiel keine Netzwerkverbindung mehr aufgebaut werden.
./cyclictest -p 80 -t5 -n
19 min lange Messung
Die Messung zeigt deutlich, das ein nicht RT gepatchter Kernel nicht für RT Anwendungen zu gebrauchen ist.
./cyclictest -p 80 -t5 -n
83 min lange Messung
sudo ./cyclictest -n -p80 -l46800000 -i1000 -h1000 -q > histogramm.log