Echtzeit Extreme Leistungssteigerung mit den neuesten Connext DDS- und ROS 2-Benchmarks

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Real-Time Innovations International - Zweigniederlassung Deutschland

Wie Sie die ROS-Performance mit neuesten Benchmarks steigern.

Mit der zunehmenden Komplexität verteilter Echtzeitsysteme werden auch die Faktoren, welche die Leistung der Systeme beeinflussen, immer komplexer zu modellieren und zu testen. Die Hochrechnung von Ergebnissen aus vereinfachten Leistungstests oder nicht repräsentativen Implementierungen ist mit Vorsicht zu genießen. Bevor man sich auf die Ergebnisse von Benchmark-Tests verlässt, sollte man sicherstellen, dass die Testbedingungen auf die eigene Anwendungsarchitektur und das Design anwendbar sind. So werden beispielsweise ROS-2-Systeme fast immer unter Einsatz mehrerer Prozesse aufgebaut, die es ermöglichen, das System schlank, modular und wartbar zu gestalten. Man sollte also mehrere Prozesse in den Testbedingungen berücksichtigen.

Ohne diese praxisnahen Überlegungen wird der Benchmark-Leistungstest wahrscheinlich zu irreführenden Ergebnissen führen. Genauere Ergebnisse liefern repräsentative, reale Konfigurationen, die Skalierbarkeitsanforderungen, große Datensätze und eine Many-to-many-Topologie berücksichtigen. Um ein genaues Bild der Leistung zu erhalten, muss man überprüfen, was die Benchmarks wirklich aussagen und ob sie auf das eigene Systemdesign anwendbar sind.

Spitzenleistung ist für jedes Projekt entscheidend. Connext® DDS wurde entwickelt, um einen Durchsatz zu bieten, der mit der Größe der Nutzlast skaliert und eine sehr niedrige Latenzzeit aufweist. Dieser Beitrag führt durch aktuelle Tests mit Open-Source-ROS-2-Benchmarks. Er vergleicht die Leistung von Connext DDS mit der anderer DDS-Implementierungen unter Verwendung einiger öffentlicher Benchmarks, wie z. B. denjenigen, die auf der nächtlichen CI-Build-Farm von Open Robotics ROS 2 verwendet werden. Dabei werden insbesondere die kritischen Leistungsbereiche gemessen: Latenz, Durchsatz und Zuverlässigkeit (Paketverluste).

Integrierte Benchmark-Anwendungen

Die gängigsten Anwendungen zum Testen der Leistung des ROS 2 Middleware Wrapper (RMW) haben einen gemeinsamen Ursprung in der Apex-Anwendung performance_test. Dazu gehören Gabelungen (Forks) und Varianten von iRobot, dem Barkhausen Institut und dem performance_test, das auf der nächtlichen ROS 2-Build-Farm läuft.

Für den ersten Teil dieses Tests wird der Test der ROS 2-Build-Farm verwendet, um die Ergebnisse der nächtlichen ROS 2-Build-Site zu replizieren. Durchgeführt wird dieser Test auf einem Dell G7-Notebook-PC unter Ubuntu 20.04.

Das Abrufen und Erstellen der Anwendung ist einfach und sollte ohne Fehler ablaufen. Die Testanwendung kann direkt ausgeführt werden; es ist nicht notwendig, "ros2 run (Paketname) (Anwendungsname)" aufzurufen. Sie nimmt Befehlszeilenargumente entgegen, um den Test zu steuern, und erstellt eine sequentielle Protokolldatei mit den Ergebnissen. Die Tests werden für jeden Datentyp einzeln und mit unterschiedlichen Veröffentlichungsraten mit jeder ROS RMW-Variante durchgeführt – was eine große Anzahl von Tests und Protokolldateien zur Folge hat. Um diesen Prozess zu automatisieren, haben wir ein Shell-Skript entwickelt, das jede Testvariante durchläuft, und ein Python-Skript, das die Hunderte von Protokolldateien zu einem einzigen Bericht zusammenfasst.

Die bei diesem Test erzielten Ergebnisse ähneln denen, die auf der nächtlichen ROS-2-Build-Site veröffentlicht wurden. Wir haben diesen Test für einen direkten Vergleich (Äpfel mit Äpfeln) durchgeführt, aber es ist wichtig, das Folgende zu beachten:

• Die nächtliche Performance von ROS 2 verwendet eine ältere (und jetzt veraltete) "rmw_connext_cpp". RMW. Dies war die erste RMW-DDS-Schicht, die entwickelt wurde, und hat bekannte Leistungsprobleme, die durch unnötige Speicherzuweisungen und Kopien in der RMW-Schicht selbst verursacht werden. Dies wurde nun in zwei neuen RMW namens "rmw_connextdds" und "rmw_connextddsmicro" – beide von RTI beigesteuert – behoben, in den nächtlichen ROS 2-Builds enthalten 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 Anwendungs-Threads in einem einzelnen Prozess ist keine Middleware erforderlich. Die Threads können Daten und Datenreferenzen direkt über den vom Prozess bereitgestellten gemeinsamen Speicherbereich austauschen. Daher sind die Ergebnisse von Leistungstests, die mit einem einzelnen Prozess durchgeführt werden, nicht repräsentativ für die Ergebnisse realistischer Systeme.

Test eines realistischeren ROS-2-Systems

Als Proof of Concept wurde eine Reihe von (3) ROS 2-Anwendungen zusammengestellt, die im gleichen Stil wie die ROS 2-Tutorial-Beispiele für „Writing a simple publisher and subscriber (C++)" geschrieben sind. Mit anderen Worten: Dieser Test ist so „ROS 2", wie er nur sein kann.

Der Test besteht aus 3 Arten von ROS 2-Knoten, die in separaten Prozessen laufen:

• SOURCE-Knoten, der eine Nachricht mit einem embedded Zeitstempel veröffentlicht.

• WORK-Knoten (optional), der eine Nachricht abonniert, seinen eigenen Zeitstempel hinzufügt und sie dann in einem separaten Thema erneut veröffentlicht.

• SINK-Knoten, der eine Nachricht abonniert, sie mit einem Zeitstempel versieht, dann die bei jedem Schritt beobachteten Latenzen berechnet, Statistiken und Histogrammdaten sammelt und die Ergebnisse in Dateien schreibt.

Wie die integrierten Tests akzeptiert auch dieser Test Argumente für verschiedene Größen, Pub-Raten, RMW-Typen usw. Sie wurden lediglich zu kleinen, fokussierten Tests gestaltet, die in separaten ROS 2-Prozessen laufen, um ein eingesetztes ROS 2-System zu imitieren.

Dieser Test ist so konzipiert, dass er viele verschiedene Systemkonfigurationen unterstützt, indem er so viele SOURCE-, WORK- und SINK-Knoten wie nötig anordnet: 1:1, 1:N, N:1, N:N, lange Ketten in Reihe, parallel, usw. – was auch immer den Anforderungen Ihres Systems entspricht. Für diesen Test kommt ein einfaches SOURCE->SINK-Arrangement zum Einsatz (ohne WORK-Notizen), das der primären Konfiguration des nächtlichen ROS-2-Build-Tests entspricht.

Die Testanwendung wird auf die gleiche Weise wie jede andere ROS 2-Anwendung erstellt: in ein Verzeichnis herunterladen, colcon build ausführen, dann das Ergebnis auslesen und den Test ausführen. Der Test bietet eine Vielzahl von Kommandozeilenoptionen. Um das Testen zu erleichtern, ist enthält er eine Reihe von ROS 2-Startdateien für verschiedene Systemkonfigurationen enthalten, ebenso wie Shell-Skripte zur Automatisierung des Testens.

Um beispielsweise einen Schnelltest aller RMW-Typen über eine breite Palette von Datengrößen durchzuführen, der in etwa 3 Minuten abgeschlossen ist, führen Sie Folgendes aus:

Dies ist bei weitem kein umfassender Benchmark-Test, aber er ist näher an den realen ROS-2-Systemen und liefert bereits einige interessante, nicht intuitive Ergebnisse.

Vergleich der Ergebnisse

Eines der auffälligsten Ergebnisse ist die enorme Verbesserung der Leistung durch die beiden neuen RMWs für RTI Connext.

Connext DDS Micro erzielt die besten Multiprozess-Ergebnisse über alle Daten und Connext DDS Professional liefert die zweitbeste Multiprozess-Leistung bei großen bei großen Datenmengen.

Die zweite Beobachtung ist die schlechte Korrelation von Multiprozess- und Einzelprozess-Testergebnissen bei einigen RMW-Implementierungen, nicht aber bei Connext:

Einige RMWs, die in den Einzelprozess-Ergebnissen eine gute Leistung zeigen, schneiden in Wirklichkeit am schlechtesten ab, wenn sie denselben Test in mehreren Prozessen durchführen.

Warum ist das so? Der Grund ist, dass einige RMWs (oder Middleware-Implementierungen) einen "prozessinternen" Trick anwenden, der aktiviert wird, wenn sich das Ziel eines Datenpakets im selben Prozess wie die Quelle befinden soll. In diesem Fall wird eine Abkürzung genommen, die die DDS-Serialisierung, das Protokoll und die Transportstapel umgeht, um eine prozessgleiche Zustellung zu erreichen. Dies kann die Leistung verbessern, aber nur, wenn das eigene ROS-2-System ebenfalls aus einem einzigen Prozess besteht. Dies ist für ROS 2 sehr ungewöhnlich und geht mit einer Einschränkung der Modularität einher (d. h., es wird ein Teil der Kopplung zwischen Publishern und Subscribern eingeführt).

Die lokale Auslieferung in einer Einzelprozessanwendung hat ihren Nutzen, ist aber in den meisten Fällen nicht repräsentativ für ein eingesetztes System. Und wenn man ein System entwirft, das von der Bereitstellung mehrerer ROS-Knoten im selben Prozess abhängt und das zusätzliche Quäntchen Leistung bei großen Daten benötigt, kann man dies auch erreichen, indem man einen Daten-Pointer und nicht die Daten selbst sendet.

Übrigens unterstützt Connext DDS auch einen Zero Copy Modus, der die Leistung beim Senden großer Daten innerhalb eines Prozesses oder über Shared Memory erhöhen kann. Zudem umgeht der von Connext genutzte Zero-Copy-Ansatz nicht die Serialisierung und das Protokoll und verursacht daher keine unerwünschten "Kopplungs"-Nebeneffekte. Aber die eingesetzte Connext Zero Copy nutzt eine spezielle API, die nicht auf die ROS RMW API abgebildet werden kann. Mit rtiperftest (dem RTI-Performance-Benchmarking-Tool) lassen sich die Vorteile der Zero-Copy-Funktion sowie umfangreichere Leistungsszenarien untersuchen.

Und das führt uns zum Ausgangspunkt dieses Beitrags: Benchmarks können wertvoll sein, wenn sie unter realistischen Bedingungen für den jeweiligen Anwendungsfall durchgeführt werden.

Der Autor

Neil Puthuff ist leitender Software-Integrationsingenieur bei Real-Time Innovations mit Schwerpunkt auf Robotik und Automobilsystemen und RTI-Teamleiter für die Indy Autonomous Challenge. Er hat Erfahrung sowohl mit Hardware als auch mit Software. Bevor er zu RTI kam, entwickelte er bei Green Hills Software die Produkte Processor Probes und Replay Debugging. Neil ist bei mehr als einem Dutzend US-Patenten als Erfinder genannt.

 (mbf)

(ID:49450755)