Verteilte Echtzeitsysteme werden immer komplexer – genau wie die Faktoren, die die Leistungsfähigkeit der Systeme beim Modellieren und Testen beeinflussen. Das Extrapolieren der Ergebnisse aus vereinfachten Performance-Tests oder einer nicht repräsentativen Softwareverteilung muss sorgfältig durchgeführt werden. Bevor Anwender sich auf die Ergebnisse von Benchmark-Tests verlassen können, müssen sie sicherstellen, dass die Testbedingungen zur Architektur und dem Design ihrer Anwendung passen. ROS-2-Systeme werden z.B. fast immer in mehreren Prozessen erstellt, die es dem System ermöglichen, schlank, modular und wartbar zu sein. In den Testbedingungen sollten sich also immer mehrere Prozesse widerspiegeln. Zudem lassen sich exaktere Ergebnisse durch repräsentative, praxisnahe Setups erzielen. Eine bestmögliche Performance für jedes Projekt ist also entscheidend. So wurde RTI Connext DDS dafür entwickelt, einen Datendurchsatz zu erzielen, der sich sowohl auf die Nutzdaten skaliert als auch eine sehr geringe Latenz bietet. Wie verhält sich Connext also unter realen Bedingungen?
Integrierte Benchmark-Applikationen
Die am häufigsten verwendeten Applikationen zum Testen der Performance der ROS 2 Middleware Wrapper (RMW) haben eine gemeinsame Codebasis. Derselbe Test wurde auf der Seite von ROS 2 Nightly CI Build angewendet, um die veröffentlichten Ergebnisse zu replizieren. Dabei kam Folgendes raus:
- Die ROS 2 Nightly Performance verwendet ein mittlerweile veraltetes „rmw_connext_cpp.“-RMW. Bei dieser ersten entwickelten RMW-DDS-Layer sind Leistungsprobleme bekannt, die durch unnötige Speicherzuweisungen und Kopien in der RMW-Layer selbst verursacht wurden. Dies wurde nun in zwei neuen RMW mit den Namen „rmw_connextdds“ und „rmw_connextddsmicro“ von RTI behoben, die beide in den ROS 2 Nightly Builds verfügbar sind.
- Der Nightly-Build-Test führt alles in einem einzigen Prozess aus. Die meisten ROS-2-Systeme bestehen jedoch aus mehreren Prozessen.
Warum ist das wichtig? Für die Kommunikation zwischen Applikations-Threads in einem einzigen Prozess ist keine Middleware erforderlich. Threads können Daten und Datenreferenzen direkt über den vom Prozess bereitgestellten gemeinsamen Speicherplatz austauschen. Daher sind die Ergebnisse des Performance-Tests, die mit einem einzigen Prozess ausgeführt werden, nicht repräsentativ für realistische Systeme.
Testen eines realistischen ROS-2-Systems
Als nächstes folgt ein Benchmark-Test, der eher einem ROS-2-System aus einer realen Produktionsumgebung ähnelt. Als Proof of Concept wurde eine Reihe von ROS-2-Applikationen zusammengestellt, die im gleichen Stil wie die ROS-2-Tutorial-Beispiele für das „Schreiben eines einfachen Publisher und Subscriber (C++)“ geschrieben wurden. Mit anderen Worten, dieser Test ist so ROS 2 wie nur möglich.
Der Test besteht aus drei Arten von ROS-2-Nodes (SOURCE, WORK, SINK), die in separaten Prozessen ausgeführt werden, die jeweils die Latenz der zugrundeliegenden RMW-Implementierung messen, während Daten durch das System geleitet werden. Der Test unterstützt viele verschiedene Systemkonfigurationen, indem so viele SOURCE-, WORK- und SINK-Nodes wie nötig arrangiert werden. Für diesen Test kommt eine einfache SOURCE->SINK-Anordnung ohne jegliche WORK-Nodes zum Einsatz, die der primären Konfiguration des Nightly-ROS-2-Build-Tests entspricht. Die Testanwendung ist als normales ROS-2-Paket wie bei jeder anderen ROS-2-Anwendung aufgebaut. Das ist weit entfernt von einem umfassenden Benchmark-Test, jedoch enger an realen ROS-2-Systemen ausgerichtet und liefert bereits einige interessante, nicht-intuitive Ergebnisse.
Vergleich der Ergebnisse
Eines der auffälligsten Ergebnisse ist die Verbesserung der Performance beider neuer RMWs für RTI Connext. Connext DDS Micro erzielt die besten Ergebnisse für mehrere Prozesse über alle Datengrößen hinweg, Connext DDS Professional bietet die nächstbeste Performance für mehrere Prozesse mit großen Datenmengen.