Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen

Für die Bestimmung der Echtzeitfähigkeit aktueller Computerboards mit modernen Hochleistungsprozessoren ist die klassische Pfadanalyse ungeeignet, doch mit empirischen Testverfahren lässt sich die Größenordnung...

Für die Bestimmung der Echtzeitfähigkeit aktueller Computerboards mit modernen Hochleistungsprozessoren ist die klassische Pfadanalyse ungeeignet, doch mit empirischen Testverfahren lässt sich die Größenordnung der maximalen Systemlatenz bestimmen. Der erforderliche Aufwand richtet sich danach, ob eine neue Hardware entwickelt wurde, ein definiertes System in einem speziellen Anwendungsfall zu testen ist oder Tests im Rahmen der kontinuierlichen Qualitätskontrolle erfolgen sollen.

Von Carsten Emde, Thomas Gleixner und Robert Schwebel

Damals, in den guten alten Tagen des Mikroprozessors, gab es noch keinen nennenswerten Cache und keine Mehrprozessorsysteme, und jedes Peripheriegerät verfügte über einen eigenen Interrupt oder einen eigenen Interruptvektor. Damals war es möglich, die maximale Latenz eines Systems theoretisch zu bestimmen. Für diesen Zweck suchte der Entwickler den längstmöglichen Codepfad, addierte die Anzahl der dafür erforderlichen CPU-Zyklen und multiplizierte das Ergebnis mit der jeweiligen Zyklusdauer des verwendeten Systems. Wer sicher sein wollte, bei dieser Pfadanalyse keinen Weg zu vergessen, führte sicherheitshalber noch Latenzmessungen durch. Jahrelang war die Pfadanalyse ein verlässliches Mittel zur Bestimmung der maximalen Latenz eines Computersystems.

Seit der Einführung von teilweise sehr großen Cache-Speichern, die häufig in komplexer Weise hintereinander geschaltet beziehungsweise von mehreren Prozessorkernen benutzt werden, von konkurrierenden Bus-Mastern bei DMA- und Mehrprozessor-Systemen und von gemeinsam benutzten Interruptleitungen ohne Vektorisierung ist die theoretische Bestimmung der höchstmöglichen Latenz eines Computersystems durch Pfadanalyse jedoch extrem erschwert oder sogar unmöglich geworden. Selbst wenn in einzelnen Fällen die Bestimmung noch machbar erscheint, ist nicht auszuschließen, dass dabei der eine oder andere Verzögerungseffekt übersehen wurde. Für diese Fälle und für solche, in denen die Pfadanalyse von vornherein ausgeschlossen ist, muss es Methoden zur Latenzmessung geben, welche die empirische Bestimmung der maximalen Latenz eines Computersystems gestatten. Neben derartigen Latenzmessungen sind aber auch Messbedingungen zu definieren, die den Prüfling einer definierten Last aussetzen, um damit potenzielle Latenzquellen sichtbar zu machen. Denn ein Computersystem ohne Last wartet gewissermaßen ständig auf ein Ereignis und kann daher in der Regel auch sehr kurzfristig auf ein solches reagieren.

Zunächst einmal ist aber zu definieren, mit welcher Anforderung Latenzmessungen erfolgen: Handelt es sich um die Messung bei einem Hard- oder Softwarehersteller, gilt es also, sämtliche unter irgendwelchen Umständen jemals möglichen Latenzen aufzudecken? Oder führt ein Maschinenbauer die Messung an einer speziellen Anlage durch, geht es also in erster Linie um Latenzen, die unter den individuellen Konfigurationsund Lastbedingungen dieser Anlage auftreten können? Weiterhin ist zu unterscheiden, ob die Messung einmaliger und grundsätzlicher Natur ist (also zum Beispiel vor der Festlegung auf eine bestimmte Hard- und Softwarekonfiguration) oder ob es sich um wiederholte Messungen zur kontinuierlichen Qualitätskontrolle handelt. Im letzteren Fall sind natürlich in erster Linie die im Rahmen der Produktpflege weiterentwickelten beziehungsweise veränderten Komponenten zu überprüfen. Entsprechend ist dieser Artikel eingeteilt in komplette »Über-Alles-Messungen«, also die Fahndung überall im System nach irgendwie möglichen Latenzen, und spezielle Messungen individueller Systeme, also das Bestimmen der höchstmöglichen Latenz, die unter den spezifischen Einsatzbedingungen einer Konfiguration auftreten kann.

Obwohl die Konzepte und Methoden in diesem Artikel für die meisten Betriebssysteme zutreffen, beziehen sich die Beispiele in erster Linie auf »Mainline-Linux«, das mit den so genannten »Realtime-Preempt-Patches« echtzeitfähig gemacht wurde. Nähere Angaben dazu finden sich im Realtime-Wiki (rt.wiki.kernel.org) und auf der Webseite des Open Source Automation Development Lab (OSADL).

1. Teil: Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
2. Teil: Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
3. Teil: Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
4. Teil: Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
5. Teil: Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
6. Teil: Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen
7. Teil: Echtzeitfähigkeit von Linux-Systemen empirisch bestimmen