Neue Connext-DDS- und ROS-2-Benchmarks
Mehr Performance
Tests zu Open-Source-ROS-2-Benchmarks vergleichen die Leistung von Connext DDS mit anderen DDS-Implementierungen unter Verwendung bekannter Benchmarks, wie sie etwa in der Open Robotics ROS 2 Nightly CI Build Farm verwendet werden. Insbesondere die kritischen Leistungsbereiche Latenz, Durchsatz und Zuverlässigkeit werden hier gemessen.
(Bild: ©Ong-ad Nuseewor/istockphoto.com)
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.
