Software
Echtzeit im Echtheits-Test
Fortsetzung des Artikels von Teil 2
Das OSADL Echtzeit-Testzentrum
Im OSADL Echtzeit-Testzentrum sind die Prüflinge auf einzeln entnehmbaren Testtabletts in Racks von jeweils acht Systemen angeordnet. Diese Testracks wurden vom Linux-Kernel-Entwickler Thomas Gleixner konzipiert und sind speziell für Embedded-Systeme und für hardwarenahe Entwicklungsarbeiten vorgesehen.
Auf den Testtabletts befinden sich je eine standardisierte Netzwerk- und Seriell-Verbindung. Diese sind rackseitig mit einem portmirror-fähigen Netzwerk-Switch und einem seriellen Netzwerk-Adapter verbunden. Letzterer verfügt über eine Log-Funktion, mit welcher die gesamte serielle Kommunikation auf einem NFS-Server gespeichert werden kann.
Nicht zuletzt ist ein netzwerkgesteuerter Schalter für die Versorgungsspannungen der Prüflinge vorhanden, mit dem jedes einzelne System gestartet, angehalten und neu gebootet werden kann. Zum Zeitpunkt der Erstellung dieses Artikels befanden sich die in der Tabelle aufgelisteten Prozessoren im Test.
Jobangebote+ passend zum Thema
| Architektur | Hersteller | Prozessor | Taktfrequenz | Bitbreite |
|---|---|---|---|---|
| x86 | AMD | LX800 | 500 MHz | 32 bit |
| K6 3D | 333 MHz | 32 bit | ||
| Athlon XP 2000+ | 1667 MHz | 32 bit | ||
| Athlon 64 2800+ | 1800 MHz | 64 bit | ||
| Phenom II X6 | 3200 MHz | 64 bit | ||
| Intel | Pentium | 133 MHz | 32 bit | |
| Pentium II Klamath |
233 MHz | 32 bit | ||
| Atom N270 | 1600 MHz | 32 bit | ||
| Atom D510 | 1667 MHz | 64 bit | ||
| Atom Z530 (Standard-Kernel als Referenz) | 1600 MHz | 32 bit | ||
| Celeron M | 1500 MHz | 32 bit | ||
| Pentium M dual-core | 2300 MHz | 32 bit | ||
| Xeon | 2800 MHz | 32 bit | ||
| Core 2 Duo | 2400 MHz | 64 bit | ||
| Core 2 Quad | 2400 MHz | 32 bit | ||
| i7 Nehalem 975 | 3333 MHz | 32 bit | ||
| i7 Gulftown X980 | 3333 MHz | 64 bit | ||
| VIA | C3 Samuel 2 | 533 MHz | 32 bit | |
| C3 Nehemiah | 533 MHz | 32 bit | ||
| C7 | 1000 MHz | 32 bit | ||
| ARM | Marvell | SheevaPlug | 1200 MHz | 32 bit |
| Texas Instruments | AM3517 | 600 MHz | 32 bit | |
| PowerPC | Freescale | MPC 5121 | 400 MHz | 32 bit |
| MIPS | ICT | Loongson | 800 MHz | 64 bit |
Prozessoren im OSADL Echtzeit-Testzentrum. Bei Taktfrequenz, Bitbreite und Prozessor-Topologie wurde auf eine möglichst große Vielfalt geachtet. Der Systemspeicher reicht von 64 Mbyte bis 12 Gbyte, Dateisysteme wurden von ext2 bis ext4 aufgesetzt.
Alle Systeme laufen im Dauerbetrieb, sämtliche Messabläufe werden automatisch gesteuert. Bei Vorliegen einer neuen Kernel-Version wird diese auf vielen Systemen automatisch generiert und eingespielt. Bei einigen Embedded-Systemen ist allerdings noch manuelle Intervention erforderlich.
Alle Systeme laufen jeweils über sechs Stunden (1 bis 7 Uhr und 13 bis 19 Uhr) unter Leerlaufbedingungen und in der übrigen Zeit unter Last durch Cyclictest bzw. in Last-Kombination von Cyclictest mit einer definierten CPU-, Speicher- und Netzwerk-Last.
Unmittelbar nach Systemstart werden die Kernel-Histogramme für Wake- up-Latenz, Timer-Offset und deren Summe eingeschaltet. Mit Hilfe des Monitoring-Systems Munin [2] wird alle fünf Minuten die maximale Latenz aus den Kernel-Histogrammen ausgelesen und in der Round-Robin-Datenbank RRD [3] abgelegt. Danach wer- den die Kernel-Histogramme in der oben beschriebenen Weise zurückgesetzt.
Bild 1 zeigt als Beispiel von Munin erzeugte Abbildungen eines 30-Stunden-Zeitraums. Es handelt sich um einen Intel-Core-2-Duo-Prozessor mit 2,4 GHz Taktfrequenz, der unter den oben beschriebenen Lastbedingungen betrieben wurde, was an der gleichzeitig abgebildeten CPU-Last erkennbar ist. In diesem Fall wurde während der Leerlaufphase noch ein vierstündiger Test einer Echtzeit-Ethernetverbindung dazwischengeschaltet, der zu einer erhöhten Interrupt-Frequenz, nicht aber zu einer sichtbaren CPU-Belastung führt.
Sollte einmal eine unerwartete Latenz auftreten, deren Ursache gesucht und beseitigt werden muss, ergibt sich z.B. der in Bild 2 gezeigte Kurvenverlauf. Deutlich erkennt man die gegen 15 und 5 Uhr aufgetretenen Latenzen der CPU Nummer 0 von 520 bzw. 200 µs.
Am Ende des Cyclictest-Programms werden die Histogramme ausgelesen und graphisch dargestellt. Dabei wird - wie allgemein empfohlen - die Anzahl an Messwerten pro Latenz-Kategorie in der y-Achse logarithmisch dargestellt, während die Latenzwerte auf der x-Achse linear skaliert werden. Bild 3 zeigt auf diese Weise gewonnene Latenz-Plots von zwei mit Echtzeit-Kerneln und einem mit Standard-Kernel ausgerüsteten Systemen.
Um auf besondere Vorkommnisse im Testzentrum rasch reagieren und alle Ereignisse langfristig archivieren zu können, wurde das Munin-System mit Nagios-Monitoring [4] verbunden.
Zum einen lässt sich Nagios dahingehend konfigurieren, dass je nach Art des Ereignisses E-Mail, SMS, Telefax oder ähnliches an eingetragene Kontaktpersonen versandt werden. Zum anderen verfügt Nagios auch über sehr weitgehende Archivier- und Suchfunktionen, mit denen einzelne Ereignisse im Zeitverlauf analysiert und charakterisiert werden können. OSADL-Mitgliedsfirmen können diese Archivdaten für ihr internes Qualitäts-Management, für MTBF-Bestimmungen und für Zertifizierungen nutzen.
Ergebnisse online verfügbar
Auf der OSADL-Website [5] können Arbeitsweise und Ergebnisse des Testzentrums von jedermann verfolgt werden. Es sind sowohl die kontinuierlichen Latenzregistrierungen als auch die Latenzplots der Testsysteme verfügbar. Die Daten werden unmittelbar nach Vorliegen auf den OSADL-Internetserver übertragen; bei den Latenzregistrierungen beträgt das Update-Intervall 5 Minuten, bei den Latenzplots 12 Stunden.
Damit die Ergebnisse des OSADL-Testzentrums an anderer Stelle reproduziert werden können, werden alle relevanten Daten der Testsysteme ebenfalls kontinuierlich generiert und auf der genannten OSADL-Website alle 12 Stunden aktualisiert. Im einzelnen handelt es sich dabei um:
- Name und Hersteller des Mainboards,
- Version und Hersteller des BIOS,
- Distribution,
- Kernel-Version, Kernel-Parameter, Kernel-Konfiguration,
- Cyclictest-Kommandozeile,
- Charakteristika, Cache und Taktfrequenzen der CPU,
- Auflösung der Timer,
- Größe und Kenndaten des Systemspeichers, DIMM-Analyse,
- installierte Peripheriesysteme am PCI-Bus.
Ausgereifte Kernel-Version
Während der Stabilisierungsphase der kürzlich freigegebenen „Latest Stable“-Echtzeit-Version des Linux-Kernels 2.6.33 wurde erstmals auf die Daten des OSADL Echtzeit-Testzentrums zurückgegriffen. Diese Kernel-Version wurde erst dann als „Latest Stable“ freigegeben, nachdem sämtliche in den Testsystemen aufgetretenen Fehler beseitigt waren und alle Systeme über mehrere Wochen fehlerfrei und unter Einhaltung der vorgegebenen Echtzeit-Bedingungen lauffähig waren. Dies hat zwar zu einem verzögerten Release geführt. Auf der anderen Seite liegt dadurch nun ein echtzeitfähiger Linux-Kernel vor, dessen Eigenschaften und Produktionsreife in weiten Bereichen garantiert werden kann.
- Echtzeit im Echtheits-Test
- Kernel für Echtzeit-Messaufgaben konfigurieren
- Das OSADL Echtzeit-Testzentrum
- Literatur & Autor
Das könnte Sie auch interessieren
Betriebssysteme:
Echtzeit-Performance mit 64-bit-Windows
Embedded Design
Windows-Echtzeit-Erweiterung oder DSPs – wer ist schneller?
