Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
Fortsetzung des Artikels von Teil 1
Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
Vom Signal zum Anwenderprogramm
Jobangebote+ passend zum Thema
Bild 1 zeigt den Verlauf eines Eingangssignals einer exemplarischen Maschinensteuerung. Als Beispiel dient hier das Signal einer Lichtschranke zur Steuerung einer Förderbandweiche.
Nach einem bestimmten Zeitintervall, das einen vordefinierten Wert nicht überschreiten darf, muss das Anwenderprogramm zur Ausführung kommen und die Förderbandweiche betätigen. Ist dies wegen einer zu langen Latenz nicht der Fall, kommt es zu einer Fehlfunktion der Maschine.
Mögliche Verzögerungen können sich in den verschiedenen Segmenten ergeben, die das Signal durchlaufen muss:
Gatter-Latenz:
Der Controller, an den das Ausgangssignal der Lichtschranke (z.B. TTL) angeschlossen ist, muss das Signal verarbeiten und am Ende dieser Verarbeitung die Interruptleitung des Prozessors aktivieren.
Diese Zeit beträgt meist deutlich weniger als 1 μs, aber bei Fehlkonfiguration beziehungsweise Fehlfunktion des Controllers oder zu starker Dämpfung des Eingangssignals können in diesem Segment nennenswerte Latenzen entstehen.
CPU-IRQ:
Nachdem die Interruptleitung des Prozessors aktiviert ist, muss dieser die aktuelle Verarbeitung unterbrechen, den Kontext sichern, die zu diesem Interrupt gehörende Interruptroutine bestimmen, den erforderlichen Kontext bereitstellen und mit der Ausführung der Interrupt-Serviceroutine beginnen. Auch dieses Segment wird in der Regel in sehr kurzer Zeit durchlaufen, kann aber in einzelnen Fällen ebenfalls durchaus Ursache für Systemlatenzen sein, wenn beispielsweise bei Systemen mit Daten- oder Befehls-Cache für den Wechsel des Kontextes keine freien Cache-Linien verfügbar sind beziehungsweise der Code nicht aus dem Cache ladbar ist und daher Speicherzugriffe notwendig werden.
Interrupt-Serviceroutine:
Diese besteht meist aus zwei funktional sehr unterschiedlichen Bestandteilen: Die erste Phase der Interrupt-Serviceroutine ist von häufigen Hardwarezugriffen geprägt. Diese sind erforderlich, um die Interruptlogik des Controllers zurückzusetzen und den Datentransfer vorzubereiten. Wenn sich mehrere Geräte eine Interruptleitung teilen, muss die Routine sogar noch die verschiedenen in Frage kommenden Geräte abfragen. Die zweite Phase regelt dann den Datentransfer, der mit dem jeweiligen Interrupt verbunden ist. In vielen Fällen kann aber schon nach Abschluss der ersten Phase die Kontrolle wieder an den Kernel zurückgehen, sodass die zweite Phase dann im Wechsel mit anderen Prozessen ablaufen kann.
Scheduling und Kontext-Wechsel:
Sobald feststeht, welcher Prozess auf Daten des Gerätes wartet, das den Interrupt ausgelöst hat, und der Datentransfer beginnen kann, weckt der Kernel den wartenden Prozess auf. Dieser so genannte Wakeup-Vorgang bedeutet, dass der betroffene Prozess in die Warteschlange der aktiven Prozesse aufgenommen und je nach dessen Priorität ausgeführt wird. Für die Ausführung muss der Kernel den Kontext des Programms bereitstellen, in den Usermodus wechseln und den Prozessor das wartende Programm abarbeiten lassen.
Komplette Messung: Wo sind die Latenzen?
Zur Messung möglicher, irgendwo im System auftretender Latenzen speist man ein Eingangssignal für einen dafür geeigneten Controller ein, installiert ein Anwenderprogramm, das auf das Eintreffen dieses Signals wartet, und misst das Zeitintervall zwischen der Einspeisung des Signals und dem Beginn der Ausführung des Anwenderprogramms. Geeignete Eingangscontroller sind beispielsweise universelle digitale Input-Controller (GPIO), ersatzweise lässt sich aber auch die Eingangs-Handshake-Leitung eines seriellen Controllers nutzen. Der Ausführungsbeginn des Anwenderprogramms sollte vorzugsweise nicht mit Hilfe eines interruptgesteuerten Ausgabegerätes markiert werden, da hierdurch eine zusätzliche Verzögerung entsteht. Am besten sind universelle Output-Controller geeignet, deren Ausgangssignal sich unmittelbar durch einen Schreibvorgang in ein Controller-Register setzen lässt.
Die beschriebene Messung erleichtert die so genannte »OSADLLatency-Box« (Bild 2), ein kombiniertes, unabhängig arbeitendes Gerät, das Triggergenerator und Messgerät vereinigt. Es stehen zwei digitale Ausgänge und vier digitale Eingänge zur Verfügung (siehe Kasten). Bis zu zwei unabhängige Messvorgänge kann das Gerät mit jeweils einem Trigger- und zwei Messkanälen ausführen. Gleichzeitig kann der zweite Messkanal zum Beispiel die Dauer vom Eingangssignal bis zum Beginn der Interrupt-Serviceroutine und von dort bis zum Ausführungsbeginn des Anwenderprogramms bestimmen. Sämtliche Messwerte speichert die »Latency-Box« in Form eines Histogramms mit einer Auflösung von 1 μs und einem Maximalwert von 1000 μs. Dabei speichert die letzte Histogramm-Zelle nicht nur die Häufigkeit von Werten zwischen 999 μs und 1000 μs sondern auch sämtliche Werte oberhalb davon. Nur wenn diese letzte Zelle am Ende einer Messung den Wert »0« enthält, kann also von einem verwendbaren Messergebnis ausgegangen werden. Anderenfalls sind Latenzwerte oberhalb von 1000 μs aufgetreten, deren genaue Größe aber unbekannt ist. Da die Messung als Ergebnis die maximale gemessene Latenz (auch »worstcase latency« genannt) liefern soll, muss natürlich sichergestellt sein, dass alle Messwerte ausschließlich innerhalb der Histogrammgrenzen von 0 μs bis 1000 μs liegen.
Die von der Firma Eltec Elektronik im Auftrag des OSADL entwickelte und gefertigte »Latency-Box« steht OSADL-Mitgliedern kostenlos leihweise zur Verfügung. Je nach Verfügbarkeit können allerdings auch Nichtmitglieder die »Latency-Box« nutzen beziehungsweise erwerben. Nach Abschluss einer Messung sind die Daten in Form einer ASCII-Datei über einen auf dem Gerät laufenden FTP-Server abrufbar. Die Rohdaten in dieser ASCII-Datei enthalten jeweils die Anzahl aufgetretener Latenzen mit einer Auflösung von 1 μs. Die weitere Verarbeitung der Daten erfolgt dann meist auf einem Desktop-PC. Für diesen Zweck stehen geeignete Skripts zur Herstellung grafischer Darstellungen mit Hilfe des Programms »gnuplot« zur Verfügung. Die Ausführung eines solchen Skripts ergibt eine Grafik, wie Bild 3 sie zeigt. Um eine optimale Beurteilung der Daten zu ermöglichen, ist die x-Achse (Latenzwerte) linear und die y-Achse (Anzahl an Messwerten pro Latenzwert) logarithmisch dargestellt. Der senkrechte Strich in grüner Farbe kennzeichnet die maximale Latenz, das wichtigste Ergebnis der Messung.
- 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
