Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
Fortsetzung des Artikels von Teil 4
Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
»Cyclictest«
Thomas Gleixner entwickelte das Progamm »cyclictest« zunächst nur als internes Test-Tool zur Ermittlung von Regressionen im Test- und Release-Verfahren der Realtime-Preempt-Patches des Linux-Kernels. Inzwischen ist es aber zum Standard-Tool für die Bestimmung der internen Latenz eines Echtzeitsystems geworden. Das Hauptprogramm »cyclictest« startet eine definierbare Anzahl an Arbeits-Threads, die zyklisch jeweils auf einen Timer-Interrupt warten und die Zeit messen, die zwischen dem erwarteten und dem tatsächlichen Ausführungsstart vergeht. Diese Zeitdifferenz wird ausgegeben, und die maximale Latenz des Systems ergibt sich aus der höchsten jemals gemessenen Zeitdifferenz. Dabei ist darauf zu achten, dass genügend Messungen erfolgen und zwischen den Messungen keine zu großen Intervalle bestehen, während derer bestehende Latenzquellen verloren gehen können. Als Faustformel sollte das Messintervall etwa doppelt so hoch sein wie die erwartete maximale Latenz des Systems und die Verzögerung zwischen den Arbeits-Threads etwa dem Messintervall geteilt durch die Anzahl an Prozessoren entsprechen. Bei einer erwarteten maximalen Latenz von 50 μs und vier Prozessoren lautet zum Beispiel der Aufruf des Programms »cyclictest« wie im Codebeispiel 4 im Kasten dargestellt.
Jobangebote+ passend zum Thema
Die Kommandozeilen-Argumente des Programms »cyclictest« bedeuten im Einzelnen:
-a
Affinity. Jeder Arbeits-Thread startet, wenn möglich, auf einer eigenen CPU, einem eigenen Prozessor-Core beziehungsweise einem eigenen Hyperthread. Gibt der Anwender ein Argument wie zum Beispiel
-a0
an, laufen die Threads ausschließlich auf diesem Prozessor.
-t
Threads. Es werden so viele Threads gestartet, wie CPUs, Prozessor-Cores beziehungsweise Hyperthreads vorhanden sind. Gibt der Anwender ein Argument wie zum Beispiel
-t4
an, wird genau diese Anzahl an Threads gestartet.
-n
Nanosleep-Clock. Dieses ist der Standard-Timer. Die anderen verfügbaren Timer sind nur zu Testzwecken implementiert und kommen meist nicht zur Anwendung.
-p99
Priorität. Diese Priorität bezieht sich auf den Thread 0. Weitere Threads erhalten jeweils diese Priorität, reduziert um die Nummer des Threads.
-i100 -d25
Thread-Intervall und Verzögerung zwischen den Threads (siehe oben).
Für die erforderliche Anzahl an Messungen lässt sich keine allgemeine Angabe machen. Es ist aber von mindestens 109 durchzuführenden Messzyklen auszugehen. Im genannten Beispiel dauert eine Gesamtmessung dann etwa einen bis anderthalb Tage.
Kernel-Latenz-Histogramme
Nach Einspielung der RT-Preemption-Patches des Linux-Kernels stehen zusätzliche diagnostische Funktionen zur Verfügung. Unter anderem handelt es sich dabei um eingebaute kontinuierliche Latenzmessungen, die in einem Histogramm – sehr ähnlich wie bei der »OSADL-Latency-Box« – abgespeichert werden. Die Auflösung beträgt auch hier 1 µs, der Wertebereich der Histogramme liegt zwischen 0 µs und 10 240 µs. Um die Messwerte auslesen zu können, muss das Debug-Filesystem ansprechbar sein. Dies erfolgt entweder durch Eingabe der in Codebeispiel 5 dargestellten Kommandozeile oder durch Hinzufügen der Zeile in Codebeispiel 6 in die Datei »/etc/fstab«, damit das Debug-Filesystem nach einem Neustart sofort ansprechbar ist.
- Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
- Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
- Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
- Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
- Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
- Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
- Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
