Echtzeit-Linux auf dem Prüfstand

Echtzeit-Linux auf dem Prüfstand

Das Überlast-Verhalten des Zielsystems wird ebenso in einem qualitativen Test geprüft. Ausgangspunkt der Untersuchungen ist ein „Normallast-Thread“, der in periodischen Abständen die CPU kurzzeitig zu 100 % belastet. Über eine Periodendauer betrachtet, belegt dieser Normallast-Thread etwa 50 % der Rechenzeit. Um kurzzeitige Überlastzustände zu generieren, wird ein zweiter Thread gleicher Priorität mit langen Ruhepausen gestartet. Dieser Überlast-Thread ist so programmiert, dass die Rechenzeit, die er beansprucht, länger ist als die Pause zwischen zwei Ausführungen des Normallast-Threads. Dies zwingt den Scheduler, die Ausführung des Normallast-Threads zu verzögern. Jeder Thread schaltet einen Ausgang des Systems auf High solange er die CPU belegt. Darüber lässt sich kontrollieren, ob beide Threads trotz der Überlast weiterhin ausgeführt werden.

Die Ausführungsfrequenz eines Teilprogramms wird hauptsächlich durch die Taskwechsel-Zeiten und die Rechenleistung der Hardware begrenzt. Um die Periodizität zu testen, wird auf dem Echtzeit-System ein Thread mit steigender Frequenz gestartet, welcher das Signal eines Ausgangs invertiert. Das resultierende Rechtecksignal wird vom Oszilloskop auf Fehler überprüft, um die höchste fehlerfreie Frequenz zu ermitteln.

Die Interprozesskommunikation hat weniger mit der Echtzeit-Fähigkeit eines Systems zu tun, sie bildet allerdings die Schnittstelle zum Echtzeit-System. Der Benchmark ermittelt die Geschwindigkeit, mit der Daten zwischen Echtzeit-System und den nicht unter Echtzeit laufenden Programmteilen übertragen werden. Da hierfür auch in der tatsächlichen Anwendung keine Hardware-Eingänge und -Ausgänge zum Einsatz kommen, wird auf die Messung mit dem externen Oszilloskop verzichtet. Vielmehr werden stetig Pakete vom User-Space in den Kernel-Space und zurück kopiert und über ein Zeitintervall erfasst. Die ermittelte Paketanzahl ist ein Maß für die Geschwindigkeit der Interprozesskommunikation.

Die Ergebnisse der Benchmarks

Anhand der Benchmarks wurden bereits verschiedene Kombinationen aus Hardware, Echtzeit-Erweiterung und Linux-Kernelversion getestet: Auf PowerPC-Boards wurde Xenomai in Verbindung mit einem Linux-Kernel der 2.6er-Serie sowie RTAI in Verbindung mit Linux 2.4 untersucht. Xenomai/ Linux-2.6, RTAI/Linux-2.6 und RTAI/Linux-2.4 wurden auf diversen Intel-Architekturen evaluiert. Der Preempt-Patch wurde in Verbindung mit einem 2.6er-Linuxkernel auf einer Intel-Architektur evaluiert.

Um festzustellen, wie sich die Echtzeit-Systeme unter Last verhalten, wurden alle Tests sowohl im Leerlauf als auch bei hoher Prozessor-Auslastung durchgeführt. Dazu wurden drei Programme gestartet, die jeweils 100 % CPU beanspruchen, um Daten von einem Pseudo-Gerät in ein anderes zu kopieren. Zusätzlich löst eine über die Netzwerkkarte des Echtzeit-Systems remote gestartete „Ping-Flut“ etliche Interrupts aus, was nochmals einen beträchtlichen Arbeitsaufwand bedeutet. Es wird somit eine Auslastung des Systems erzeugt, die unter realen Einsatzbedingungen nie auftreten sollte. In der Theorie müssen die Echtzeit-Programme weiterhin korrekt funktionieren.

Die ermittelten Benchmarks hängen von der Hardware ab und sind deswegen nur für die spezifischen Boards gültig. Sie zeigen jedoch eine Tendenz für das qualitative Verhalten der einzelnen Echtzeit-Systeme.

Der prioritätsbasierte Scheduler funktioniert bei allen getesteten Kombinationen; jeder Thread wurde mehrmals von den höher priorisierten Threads unterbrochen. Lediglich auf der PowerPC-Hardware gab es Messfehler, die auf prellende Hardware-Ausgänge zurückzuführen waren.

1. Echtzeit-Linux auf dem Prüfstand
2. Die konzeptionellen Unterschiede
3. RTAI: Probleme bei Überlast
4. Echtzeit-Linux auf dem Prüfstand