OST » Wikis » Infoportal Sie befinden sich hier: start » software » linux » cyclictest

Infoportal

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
software:linux:cyclictest:start [2016-05-27 11:11] – mgehrig2software:linux:cyclictest:start [2019-10-22 14:33] (aktuell) – graf
Zeile 2: Zeile 2:
 //Cyclictest// startet mehrere Tasks, welche periodisch aufgerufen werden. Die effektive Periodendauer wird gemessen und der Jitter wird angezeigt. //Cyclictest// startet mehrere Tasks, welche periodisch aufgerufen werden. Die effektive Periodendauer wird gemessen und der Jitter wird angezeigt.
  
-  * [[https://rt.wiki.kernel.org/index.php/Cyclictest | Projektwebseite]]+  * [[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start?s[]=cyclictest | Projektwebseite]]
  
-Ein Vortrag von der "//Embedded Linux Conference 2013//" bietet einen guten Einstig für die Benutzung des Cyclictest. Der Vortrag kann auf [[https://www.youtube.com/watch?v=f_u4r6ehZKY | Youtube]] angeschaut werden. Die PPT Folien stehen {{:software:linux:cyclictest:cyclictest_frank_rowand_ppt.pdf | hier}} zum Download bereit.+Ein Vortrag von der "//Embedded Linux Conference 2013//" bietet einen guten Einstieg für die Benutzung des Cyclictest. Der Vortrag kann auf [[https://www.youtube.com/watch?v=f_u4r6ehZKY | Youtube]] angeschaut werden. Die PPT Folien stehen {{:software:linux:cyclictest:cyclictest_frank_rowand_ppt.pdf | hier}} zum Download bereit.
  
 ===== Installation ===== ===== Installation =====
-Siehe [[https://rt.wiki.kernel.org/index.php/Cyclictest#Installation | Projektwebseite#Installation]]+Siehe [[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/rt-tests#compile-and-install | RT-Tests]]
  
-Bei der Copmpile-Fehlermeldung "src/cyclictest/rt_numa.h:23:18: fatal error: numa.h: No such file or directory" siehe [[https://rt.wiki.kernel.org/index.php/Cyclictest#Compile_failure_because_numa.h_can.27t_be_found | Projektwebseite]]+Bei der Compile-Fehlermeldung "src/cyclictest/rt_numa.h:23:18: fatal error: numa.h: No such file or directory" siehe [[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/rt-tests#compile-and-install | Compile and install]]
  
 ==== Crosscompilieren für MPC 5200 ==== ==== Crosscompilieren für MPC 5200 ====
-  - "rt-tests" auschecken <code>git clone git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git</code> Oder bereits angepasstest Repository verwenden und anschliessend bei Punkt 7 (Build ausführen) weiterfahren.<code>git clone https://github.com/MarcelGehrig/rt-tests</code> +  - "rt-tests" auschecken <code>git clone git://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git</code> Oder bereits angepasstes Repository verwenden und anschliessend bei Punkt 7 (Build ausführen) weiterfahren.<code>git clone https://github.com/MarcelGehrig/rt-tests</code> 
-  - Ins Verzeichnis werchseln<code>cd rt-test</code> +  - Ins Verzeichnis wechseln<code>cd rt-test</code> 
-  -  Im Makefile die 2. Zeile"CC?=\$(CROSS_COMPILE)gcc" zu "CC:=$(CROSS_COMPILE)gcc" ändern+  -  Im Makefile die 2. Zeile "CC?=\$(CROSS_COMPILE)gcc" zu "CC:=$(CROSS_COMPILE)gcc" ändern
   - Im File "src/cyclictest/cyclictest.c" in der Zeile 66 das Wort "static" entfernen   - Im File "src/cyclictest/cyclictest.c" in der Zeile 66 das Wort "static" entfernen
   - Im File "src/include/rt-sched.h" nach der Zeile 56 folgende Zeilen hinzufügen:<code>#ifdef __powerpc   - Im File "src/include/rt-sched.h" nach der Zeile 56 folgende Zeilen hinzufügen:<code>#ifdef __powerpc
Zeile 28: Zeile 28:
  
 ===== Anwendung ===== ===== Anwendung =====
 +IMPORTANT
 +Bei der Messung der RT-Performance müssen diverse Einflüsse beachtet werden. Im Artikel [[software:linux:preempt_rt:hinweise_messung_rt|Hinweise zum Messen eines RT-Systems]] sind die wichtigsten Einflüsse gesammelt.
 ==== Schnelle Messung ==== ==== Schnelle Messung ====
 <code>sudo ./cyclictest -p 80 -t5 -n</code> <code>sudo ./cyclictest -p 80 -t5 -n</code>
-Erzeugt 5 Threads mit höchster Priorität von **-**80 (-p) mit der Verwendung von nano_sleep() (-n). Genauere Informationen siehe [[https://rt.wiki.kernel.org/index.php/Cyclictest#Run_it | Projektwebseite#Run_it]]+Erzeugt 5 Threads mit höchster Priorität von **-**80 (-p) mit der Verwendung von nano_sleep() (-n). Genauere Informationen siehe [[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start?s%5b%5d=cyclictest | Projektwebseite]]
  
 ==== Histogramm ==== ==== Histogramm ====
-Das Histogramm zeigt auf, welche Latenzen wie oft auftreten. Mit folgendem Befehl speichert der Cycletest die Daten in Form von einem Histogram ab. +Das Histogramm zeigt auf, welche Latenzen wie oft auftreten. Mit folgendem Befehl speichert der Cycletest die Daten in Form von einem Histogramm ab. 
-<code>sudo ./cyclictest -n -p80 -l600000 -i1000 -h1000 -q > histogramm.log</code>+<code>sudo ./cyclictest -n -Sp80 -l600000 -i1000 -h1000 -q > histogramm.log</code> 
 + 
 +[{{ :software:linux:cyclictest:histograme05.jpg?400|Histogramm von einem x86 mit RT Kernel. Messzeit 1h}}]
  
 | -n          |use clock_nanosleep| | -n          |use clock_nanosleep|
-| -p80        |Priorität **-**80 (Realtime)|+| -Sp80       |S = alle Kerne; p = Priorität **-**80 (Realtime)|
 | -l600000    |600'000 Zyklen| | -l600000    |600'000 Zyklen|
 | -i1000      |1000us pro Zyklus| | -i1000      |1000us pro Zyklus|
Zeile 48: Zeile 52:
 Um das Histogramm zu plotten kann das Matlab Skript {{:software:linux:cyclictest:plothistogram.zip| plotHistogramm.m}} verwendet werden. Um das Histogramm zu plotten kann das Matlab Skript {{:software:linux:cyclictest:plothistogram.zip| plotHistogramm.m}} verwendet werden.
  
 +==== Optionen ====
 +Die vollständige Dokumentation über die Optionen findet sich auf der [[https://wiki.linuxfoundation.org/realtime/documentation/howto/tools/cyclictest/start?s%5b%5d=cyclictest | Webseite]] des Cyclictest. Die wichtigsten Optionen werden in der folgenden Liste beschrieben:
  
-===== Zu beachten ===== +| -n          |use clock_nanosleep; clock_nanosleep wird von den meisten RT-Anwendungen verwendet| 
-==== Priorität ==== +| -p80        |Priorität| 
-Normale Prozesse haben eine Priorität zwischen 0 und 39. Wobei 0 die höchste Priorität ist. RT-Prozesse haben immer eine negative Priorität. Dabei ist -99 die höchste Priorität. Bei RT wird oft von einer positiven Priorität (z.B. +80) gesprochen. Dabei ist aber eigentlich die Priorität -80 gemeint. Eine höhere Priorität als 80 (oder korrekt -80) ist 81 (oder korrekt -81).+| -l600000    |600'000 Zyklen bis der Test sich selbst beendet. Kann auch weg gelassen werden, wenn man den Test manuell mit ''CTL + C'' beendet| 
 +| -i1000      |1000us pro Zyklus| 
 +| -h1000      |maximal Latenzen bis 1000us werden im Histogramm gemessen| 
 +| -q          |quiet: keine Ausgaben während Messung. Kann wichtig sein, wenn die SSH Verbindung die Messung stört| 
 +| -m          |Der Cyclictest reserviert sich den benötigten Speicher zu beginn. Der Speicher muss nicht dynamisch zugewiesen werden.|
  
-Um sich die Priorität von Prozessen anzeigen zu lassen eignet sicht //htop// am besten. //htop// lässt sich mit dem Befehl ''sudo apt-get install htop'' installieren.+===== Messungen =====
  
-Wenn //htop// nicht installiert werden kann, kann die Priorität auch über das Terminal ausgegeben werden. Dafür muss erst mit Hilfe von //top// die PID des Hauptprozesses ermittelt werden. Die RT-Prozesse, die vom Hauptprozess aus gestartet werden, haben aufeinander folgende PIDs. Mit folgendem Befehl kann dann die Priorität eines Prozesses angezeigt werden (hier vom Prozess mit der PID = 711): 
-<code>awk '{print $18}' /proc/711/stat</code> 
-Oder um auch noch den Namen und den "Nice"-Wert auszugeben : 
-<code>awk '{print "Name: " $2, " Prio: " $18, " Nice: " $19}' /proc/<PID>/stat</code> 
- 
-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. 
- 
-==== SSH ==== 
-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. 
- 
- 
-===== Zu erwartende Ergebnisse ===== 
 ==== MPC 5200 ==== ==== MPC 5200 ====
 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. 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.
Zeile 81: Zeile 73:
 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. 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.
  
-=== Messungen ===+Die folgenden Messungen werden teilweise mit künstlicher Last wie //CacheCalibrator// oder //dd// durchgeführt. Mehr dazu unter [[software:linux:stresstests:start|Künstliche Belastungen für ein RT-System]].
 == Nur Cyclictest, ohne zusätzliche Last == == Nur Cyclictest, ohne zusätzliche Last ==
 <code># ./cyclictest -p 80 -t5 -n</code> <code># ./cyclictest -p 80 -t5 -n</code>
Zeile 92: Zeile 84:
   * T: 4 ( 3268) P:80 I:3000 C:18904904 Min:     24 Act:   54 Avg:   50 Max:     124   * T: 4 ( 3268) P:80 I:3000 C:18904904 Min:     24 Act:   54 Avg:   50 Max:     124
  
-== Mit //Cache Calibrator// als zusätzliche Last ==+== Mit Cache Calibrator als zusätzlicher Last ==
 <code>./cyclictest -p 80 -t5 -n</code> <code>./cyclictest -p 80 -t5 -n</code>
 3 min lange Messung 3 min lange Messung
Zeile 116: Zeile 108:
  
 Dank der hohen Priorität des Cyclictest von -80 wird er vom dd-Prozess, der eine Priorität von +20 hat, nicht beeinflusst. Dank der hohen Priorität des Cyclictest von -80 wird er vom dd-Prozess, der eine Priorität von +20 hat, nicht beeinflusst.
- 
  
 ==== x86 ==== ==== x86 ====
 Für folgende Tests wurde ein Laptop mit folgenden Kenndaten verwendet: Für folgende Tests wurde ein Laptop mit folgenden Kenndaten verwendet:
-  * 4x Intel Core i7-4600 CPU @ 2.1GHz+  * 4x Intel Core i7-4600U CPU @ 2.1GHz
   * 16GB RAM   * 16GB RAM
   * Linux Mint 17.3 Rosa   * Linux Mint 17.3 Rosa
Zeile 126: Zeile 117:
 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. 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.
  
-=== Messungen === 
 == 3.19.0-32-generic; Idle == == 3.19.0-32-generic; Idle ==
 <code>./cyclictest -p 80 -t5 -n</code> <code>./cyclictest -p 80 -t5 -n</code>
Zeile 137: Zeile 127:
   * T: 4 (16293) P:80 I:3000 C: 383109 Min:      1 Act:    2 Avg:    1 Max:    1320   * T: 4 (16293) P:80 I:3000 C: 383109 Min:      1 Act:    2 Avg:    1 Max:    1320
  
-Die Messung zeigt deutlich, das ein nicht RT gepatchter Kernel nicht für RT Anwendungen zu gebrauchen ist.+Die Messung zeigt deutlich, dass ein nicht RT gepatchter Kernel nicht für RT-Anwendungen zu gebrauchen ist.
  
 == 3.19.0-32-generic; Normaler Alltagsgebrauch == == 3.19.0-32-generic; Normaler Alltagsgebrauch ==
Zeile 156: Zeile 146:
 [{{ :software:linux:cyclictest:histograme04.jpg?400|3.18.29-rt30; RT-Kernel; ohne GUI; Histogram Overflows: 0}}] [{{ :software:linux:cyclictest:histograme04.jpg?400|3.18.29-rt30; RT-Kernel; ohne GUI; Histogram Overflows: 0}}]
  
-Das Histogramm zeigt, dass die meisten Latenzen kleiner als 250us sind. Allerdings hat es auch einige Ausreisser  von bis zu 900us zu erkennen. Die Latenzen von 40us bis 250us sind vermutlich auf die //SMIs//, welche typisch für x86 Architekturen sind, zurückzuführen. Mehr zum Thema //SMI// unter [[software:linux:preempt_rt:einfluesse_latenz|Einflüsse auf die Latenz von RT-Systemen]]. Um die Ausreisser zu erklären sind weitere Untersuchungen notwendig.+Das Histogramm zeigt, dass die meisten Latenzen kleiner als 250us sind. Allerdings hat es auch einige Ausreisser  von bis zu 900us zu erkennen. Die Latenzen von 40us bis 250us sind vermutlich auf die // SMIs//, welche typisch für x86 Architekturen sind, zurückzuführen. Um die Ausreisser zu erklären sind weitere Untersuchungen notwendig.
  
-===== Künstliche Last ===== +===== Diskussion ===== 
-[[software:linux:preempt_rt:kuenstlichelast|Künstliche Belastungen für ein RT-System]]+Neben den ausgeführten Messungen können auch die Messungen von [[https://www.osadl.org | Open Source Automation Development Lab]] als Referenz verwendet werden. Das OSADL hat ein QA Rack, in dem diverse Prozessoren bezüglich Latenz ausgemessen werden. Die [[https://www.osadl.org/Hardware-overview.qa-farm-hardware.0.html | Hardwareübersicht]] zeigt alle Prozessoren, die gerade gemessen werden. Zu beachten ist noch, dass die von OSADL verwendeten Kernel speziell gepatched sind. Die Patches sind aber veröffentlicht. 
 +Unsere Messungen der x86 Plattform scheinen nicht auf eine brauchbare RT-Performance schliessen zu lassen. Besonders die sporadisch auftretenden Ausreisser stören. Die Messungen von OSADL zeigen aber, dass auch i7-Prozessoren eine gute RT-Performance haben können. Der {{:software:linux:cyclictest:intel_r_core_tm_i7-3820qm_cpu_2.70ghz_linux_3.18.11-rt7.gif?linkonly | Latency Plot }} von OSADL des [[https://www.osadl.org/Profile-of-system-in-rack-9-slot-2.qa-profile-r9s2.0.html?shadow=0|i7-3615QE]] zeigt zum Beispiel eine viel bessere RT-Performance. Dies liegt vermutlich an den von OSADL verwendeten Patches und Kernelkonfiguration. Der oben gemessene Prozessor hat möglicherweise aber auch eine schlechtere RT-Performance, weil es sich beim i7-4600U um einen //Ultra-low power// Prozessor handelt (siehe [[http://www.intel.com/content/www/us/en/processors/processor-numbers.html|Externer Link]]). Ein //Ultra-low power// Prozessor wurde von OSADL nicht gemessen. 

Seiten-Werkzeuge

OST - Ostschweizer Fachhochschule - Campus Buchs
Uebersicht
software/linux/cyclictest/start.1464340268.txt.gz · Zuletzt geändert: 2016-05-27 11:11 von mgehrig2