Mobile-Menu

Performance von Echtzeit-Betriebssystemen richtig messen

Seite: 2/2

Anbieter zum Thema

MicroConsult Academy GmbH
emlix GmbH
RTI Real-Time Innovations

Interrupt-Latenzzeit

Entwickler müssen sich beim Einsatz eines RTOS besonders mit zeitbezogenen Leistungsmessungen auseinandersetzen. Ein wichtiges Merkmal von Embedded-Systemen ist die definierte zeitliche Reaktion auf externe Ereignisse. Meist wird ein Embedded-System durch einen Interrupt über ein Ereignis informiert, daher ist die Verzögerung zwischen dem Eintreten des Interrupts und der Reaktion auf diesen Interrupt – die Interrupt-Latenzzeit – ein kritischer Faktor. Leider gibt es mindestens zwei verschiedene Definitionen des Begriffs „Interrupt-Latenzzeit“ (siehe auch Bild 1):

System-Latenz: Gesamtverzögerung zwischen dem Feststellen eines Interrupt-Signals und dem Start der Ausführung der Interrupt Service Routine.

Betriebssystem- bzw. OS-Latenz: Die Zeit zwischen dem Start der CPU-Interruptsequenz und der Initiierung der ISR - eigentlich Betriebssystem-Overhead, häufig jedoch als Latenz bezeichnet, weshalb manche Anbieter eine Interrupt-Latenzzeit von Null angeben.

Bildergalerie

Die Interrupt-Reaktionszeit ƮIL ist die Summe aus zwei Zeiten: ƮIL = ƮH + ƮOS. ƮH ist die hardwareabhängige Zeit, also abhängig vom Interrupt-Controller auf dem Board sowie der Art des Interrupts. ƮOS ist der vom OS induzierte Overhead.

Im Idealfall liegen auch Angaben zu den Best- und Worst-Case-Szenarien vor. Worst-Case bedeutet, dass der Kernel Interrupts deaktiviert.

Für Messungen eines Zeitintervalls, wie z.B. der Interrupt-Latenz, sind geeignete Instrumente erforderlich. Am besten eignet sich hier ein Oszilloskop. Eine Möglichkeit besteht darin, einen Pin einer GPIO-Schnittstelle zum Generieren des Interrupts zu verwenden. Dieser Pin lässt sich am Oszilloskop überwachen. Beim Start der Interrupt Service Routine wird ein weiterer, ebenfalls überwachter Pin umgeschaltet. Das Intervall zwischen den beiden Signalen lässt sich einfach am Messgerät ablesen.

Viele Embedded-Systeme sind echtzeitfähig, und bei Echtzeitapplikationen sowie auch fehlertoleranten Systemen ist es wichtig, dass die Interrupt-Latenzzeit bekannt ist. Wenn gefordert ist, dass die Bandbreite an einer bestimmten Schnittstelle möglichst groß ist, muss die Latenzzeit an diesem bestimmten Interrupt gemessen werden. Bei den meisten Systemen gibt es hier keine Probleme, obwohl die Interrupt-Latenzzeiten im Mikrosekundenbereich liegen.

Scheduling-Latenzzeit

Eine wichtige Rolle bei der RTOS-Funktionalität spielt die Unterstützung einer Multithreading-Ausführungsumgebung. Bei Echtzeit-Applikationen ist wichtig, wie effizient das Scheduling von Threads oder Tasks vonstattengeht.

Zentraler Bestandteil eines RTOS ist der Scheduler; der Anwender sollte also über dessen Performance im Bilde sein. Angesichts der vielen verschiedenen Messmethoden und Auslegungsmöglichkeiten der Ergebnisse ist es schwierig, eindeutige Aussagen zu bekommen. Im Grunde genommen geht es um zwei separate Messungen:

  • Kontextwechsel-Zeit
  • Zeit-Overhead, durch das RTOS beim Task-Scheduling induziert

Die Kontextwechsel-Latenz ist die Zeit, die zur Ausführung eines Kontextwechsels erforderlich ist. Bild 2 zeigt die abgelaufene Zeit zwischen der Ausführung des letzten Befehls von Task A und des ersten Befehls von Task B. Dabei ist es meist unwesentlich, ob Task B bereits ausgeführt und dann angehalten wurde oder ob sie erstmals ausgeführt wird.

Im zweiten Szenario befindet sich das RTOS im Leerlauf und startet aufgrund eines externen Ereignisses das Scheduling einer Task. In diesem Fall ist der Overhead die abgelaufene Zeit, ehe die erforderliche Task tatsächlich ausgeführt wird (siehe auch Bild 3).

Die Scheduling-Latenz ist der Höchstwert zweier Zeiten ƮSL = MAX(ƮSO, ƮCS), wobei gilt:

  • ƮSO ist der Scheduling Overhead, vom Ende der ISR bis zum Start des Task-Scheduling
  • ƮCS ist die Zeit zum Sichern und Rückspeichern des Thread Context

Die Messungen lassen sich auf ähnliche Weise wie die Interrupt-Latenzzeitmessungen durchführen.

Für Entwickler zeitkritischer oder fehlertoleranter Systeme ist die Scheduling-Latenzzeit ein wichtiger Faktor, ebenso wie die Interrupt-Latenz; jedoch sind zwei völlig unterschiedliche Messungen und Betrachtungsweisen erforderlich.

Zeitverhalten der Kernel-Services

Die meisten RTOS haben sehr viele, oft mehrere Hundert API-Aufrufe. Zum Bewerten des Zeitverhaltens ist es wenig sinnvoll, jeden einzelnen Aufruf zu analysieren; stattdessen sollte man sich auf die häufig verwendeten Services konzentrieren.

Für die meisten RTOS gibt es vier Hauptkategorien von Serviceaufrufen:

  • Threading Services
  • Synchronisationsservices
  • Services zur Interprozess-Kommunikation
  • Speicher-Services

Fazit

Alle RTOS-Anbieter liefern mehr oder weniger ausführliche Leistungsdaten für ihre Produkte. Diese Daten sind oft hilfreich, lassen sich aber falsch auslegen und sind dann irreführend. Für Entwickler ist ein Verständnis der verschiedenen Messmethoden und der Terminologie zum Beschreiben der Ergebnisse unerlässlich. Auch gilt es, bestimmte Anforderungen gegeneinander aufzuwägen – meist Größe und Geschwindigkeit – und auch dies setzt ein gewisses Verständnis voraus, um objektive Vergleiche anstellen zu können.

Wenn bei Ihrer Applikation das Zeitverhalten eine große Rolle spielt, sollten Sie unbedingt selbst Messungen durchführen. So stellen Sie sicher, dass die Hardware- und Softwareumgebung fehlerfrei ist und die Werte auch wirklich relevant für Ihre Applikation sind.

(Übersetzung Sabine Pagler)

* Colin Walls hat über 30 Jahre Erfahrung in der Elektronikbranche gesammelt, größtenteils rund um das Thema Embedded-Software, und ist einer der Pioniere in diesem Bereich. Er ist Embedded-Softwareexperte bei Mentor Embedded (Mentor Graphics Embedded Software Division) und betreibt ein Blog auf http://blogs.mentor.com/colinwalls.

(ID:45139152)

Weiterführende Inhalte