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.

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.

Die zweite Beobachtung umfasst die schlechte Korrelation von Mehrprozess- und Einzelprozess-Testergebnissen für einige RMW-Implementierungen. Das gilt jedoch nicht für Connext. Einige RMWs, die in den Ergebnissen der Einzelprozesse eine gute Performance liefern, sind tatsächlich die schlechtesten Performer, wenn der gleiche Test für mehrere Prozesse durchgeführt wird. Das liegt an der Verwendung von Local Delivery, einer Verknüpfung, die erkennt, ob sich das Datenziel im selben Prozess wie die Quelle befindet, und den Netzwerkstapel umgeht sowie die Daten direkt an ihr Ziel verschiebt.

Für die lokale Bereitstellung in einer einzelnen Prozessapplikation gibt es Anwendungen, meistens ist das jedoch nicht repräsentativ für ein bereitgestelltes System. Hat man also ein System entworfen, das von der Bereitstellung mehrerer ROS-Nodes im selben Prozess abhängt und diese zusätzliche Performance für große Datenmengen reduzieren muss, lässt sich das auch durch das Senden eines Datenzeigers anstelle der eigentlichen Daten erreichen.

Zudem unterstützt Connext DDS einen Zero-Copy-Modus, der die Performance beim Senden großer Datenmengen innerhalb eines Prozesses oder über den gemeinsam genutzten Speicher steigern kann. Darüber hinaus umgeht der von Connext verwendete Zero-Copy-Ansatz die Serialisierung und das Protokoll nicht und verursacht daher keine unerwünschten Nebeneffekte bei der Kopplung. Allerdings verwendet die Connext Zero Copy eine spezielle API, die sich der ROS-RMW-API nicht zuordnen lässt. Mit rtiperftest, dem RTI-Performance-Benchmark-Tool, lassen sich die Vorteile der Zero-Copy-Funktion sowie umfangreichere Performance-Szenarien untersuchen.

Benchmarks können also wertvoll sein, wenn sie unter realistischen Bedingungen für den eigenen Anwendungsfall durchgeführt werden.