Echtzeit-Linux auf dem Prüfstand
Fortsetzung des Artikels von Teil 2
RTAI: Probleme bei Überlast
Interessant ist das Verhalten der Systeme bei Überlast: Während Xenomai-Lösungen die Überlast problemlos verkraften, frieren die RTAI-Kombinationen das System unwiderruflich ein.
Die Interrupt-Latenz-Messungen auf x86-Systemen ergibt bei RTAI eine Interrupt-Latenz von 9 µs. Ohne CPU-Last gibt es keine Ausreißer. Die Reaktionszeit von Xenomai ist sowohl im Leerlauf als auch unter hoher CPU-Last bei 11 µs angesiedelt; allerdings treten vereinzelt Ausreißer bis zu 42 µs auf. Da ORF in Kombination mit dem RT-Preempt-Patch im User-Space läuft und sich Interrupts im User-Space nicht ohne weiteres verarbeiten lassen, wurde der Benchmark für diese Kombination nicht ermittelt.
Bei der Jitter-Messung schneidet RTAI tendenziell besser ab als Xenomai und derRT-Preempt-Patch. Auf Intel-Plattformen erreichte RTAI mit beiden Kernel-Versionen einen Worst-Case-Jitter von 1 µs bei Leerlauf und 5 bis 17 µs unter Last. Xenomai/Linux-2.6 bleibt mit 61 µs im Leerlauf und 75 µs unter Last weit hinter den RTAI-Kombinationen. Der RT-Preempt-Patch liegt mit einem Worst-Case-Jitter von 30,3 µs zwischen RTAI und Xenomai.
Aufgrund der deutlich geringeren Taktfrequenzen haben PowerPCs in allen Kombinationen schlechtere Absolutwerte: Der Jitter von RTAI/Linux-2.4 liegt bei PowerPC bei 17,5 µs im Leerlauf und 18,7 µs unter Last. Xenomai kann auf dem PowerPC weder mit dem 2.4er- noch mit dem 2.6er-Kernel mithalten und produziert einen Jitter von 22,9 µs ohne Last und 31,8 µs unter Last.
Die Periodizität ist die Parade-Disziplin von RTAI: In Kombination mit dem Kernel 2.4 absolviert RTAI auf einer x86er- CPU 10 000 Zyklen in der Sekunde ohne Fehler, gefolgt von RTAI/Linux-2.6 mit 5000 Zyklen. Xenomai erreicht hier nur 800 Zyklen in der Sekunde und der RTPreempt-Patch reiht sich mit 1600 Zyklen wieder im Mittelfeld ein. Da dieser Benchmark direkt mit der Geschwindigkeit der Hardware zusammenhängt, sind die Ergebnisse auf dem PowerPC entsprechend schlechter.
Die Messung der Interprozesskommunikation zeigt, dass die Datenrate ebenso von der CPU-Performance abhängt. Auf der x86-Hardware erreichen alle Kombinationen im Leerlauf eine Datenrate von etwa 3,5 MByte/s, die mit ansteigender Last auf 0,5 MByte/s abnimmt.
Die Evaluierungen zeigen, dass für alle Hardware-Architekturen funktionierende Echtzeit-Erweiterungen für Embedded-Linux existieren. Bei identischer Hardware liefert RTAI in den meisten Fällen die besseren Werte bezüglich Jitter und Latentzzeit als Xenomai. Allerdings rückt die Tatsache, dass RTAI bei einer Überlast durch Echtzeit-Anwendungen das System einfrieren lässt, die Ergebnisse von Xenomai in ein besseres Licht.
Der Realtime-Preemption-Patch liefert zwar teilweise schlechtere Werte beim harten Echtzeit-Verhalten, hat aber durch seine Integration in den Mainline-Kernel von Linux Vorteile bezüglich Wartung und Systemintegration. sk
Nähere Informationen:
www.yellowstone-soft.de
www.o-r-f.de
www.xenomai.de
www.rtai.org
www.osadl.org
 | Hermann Betz ist Geschäftsführer von Yellowstone Soft in Ehingen. |
 | Peter Feuerer ist bei Yellowstone Soft Spezialist für Embedded-Linux. |
Für die qualitative Prüfung des prioritätsbasierten Schedulers werden vier Threads generiert und mit aufsteigender Priorität auf dem Probanden gestartet. Jeder Thread beansprucht für eine bestimmte Zeit im Bereich von 40 µs bis 100 ms die komplette Rechenleistung. Die Umschaltzeiten zwischen zwei Threads lassen sich über jeweils zwei Ausgänge erfassen: Der erste Ausgang (Active-Signal) signalisiert die Anforderung der Zeitscheibe durch den Thread, der die Zugriffsrechte aber aufgrund der „Preemption“ (Bevorrechtigung) eines höher priorisierten Thread nicht zwingend erhält. Der zweite Ausgang (Running-Signal) zeigt, ob die CPU diesen Thread tatsächlich bearbeitet. Durch diese Zuordnung lässt sich die Funktionalität des prioritätsbasierten Scheduling beurteilen. Um die Messzeit auf wenige Minuten zu minimieren, wurden die Periodendauer und die Dauer, die jeder Thread die volle Rechenleistung beansprucht, so gewählt, dass die Threads sich möglichst oft unterbrechen.
Das Oszilloskop erfasst dazu, welcher Thread wie oft und von wem unterbrochen wurde. Eine Unterbrechung des Thread trifft zu, wenn dessen Active-Signal auf High steht, das Running-Signal jedoch auf Low. Der für die Unterbrechung verantwortliche Thread lässt sich über dessen Running-Signal ermitteln.
- Echtzeit-Linux auf dem Prüfstand
- Die konzeptionellen Unterschiede
- RTAI: Probleme bei Überlast
- Echtzeit-Linux auf dem Prüfstand
