网络安全检测|网络安全服务|网络安全扫描-香港墨客投资移动版

表4中另一个有趣的观察结果是ROS2在传输大数据时存在许多问题。在ROS2的各种情况下，许多实验都失败了;但是，我们可以观察到Connext和OpenSplice之间的性能差异。这些对大数据的约束源于Connext和OpenSplice的最大有效载荷为64 KB。这是IP协议的最大包大小。默认情况下，使用QoS策略维护分段数据包很困难。因此，我们认为DDS不是为处理大数据而设计的。这对于分析ROS2性能很重要。例如，FastRTPS不支持大数据，因为它被设计为嵌入式系统的轻量级实现。即使是256 B的字符串也超过了FastRTPS中的最大长度。许多DDS供应商不支持使用可靠的连接和通用API发布大数据。为了发送和管理分开的数据包，这些DDS供应商提供了一个备用API，例如异步发布者和流控制器，它们尚未从ROS2中抽象出来。在我们的实验中，当数据大于64 KB时，具有可靠策略的Connext会产生错误。尽力而为策略的一些失败是由于不可靠通信导致的频繁消息丢失。当发布节点不能将数据传输到订户节点时，我们无法收集足够的样本并进行评估。若干评估在（3-b）和远程通信中失败，如表4所示。目前，上述结果表明ROS2不适合处理大型消息。

3.3 Latency Characteristics of ROS1 and ROS2

如图7，图8，图9，图10所示，在图5所示的每种情况下，都清楚了端到端延迟特性的趋势。在（2-a）和（2-b）中，ROS2使用OpenSplice和 可靠的策略，因为ROS1使用TCPROS，即可靠的通信。 在（3-a）和（3-b）中，为了评估具有大数据（例如，512KB和1MB）的等待时间，使用具有尽力而为策略的Connext。 首先，我们分析ROS2与ROS1相比的性能。 然后，我们使用不同的DDS实现和配置（例如QoS策略）来评估ROS2。

3.3.1 Comparison between remote and local cases

ROS1和ROS2远远小于远程和本地通信之间的差异。图7和图8显示了远程和本地病例的延迟中位数。由于从ROS1到ROS2以及从ROS2到ROS1的转换影响是相似的，图7和8包含单向数据。在图7中，所有延迟的行为始终为4 KB。相反，远程情况下的延迟从16 KB急剧增长，如图7和图8所示。这是因为ROS1和ROS2将消息分成15 KB数据包以通过以太网传输数据。远程和本地情况之间的这种差异对应于Machine1和Machine2之间的数据传输时间，这是在初步实验中测量的。初步实验使用ftp或http测量每个数据大小的传输时间。该对应关系表明RTPS协议和QoS策略数据对网络中的数据传输时间影响很小。此外，通过测量数据传输时间可以预测所有延迟。

3.3.2 Comparison among local, nodelet, and intraprocess cases

 在小数据和大数据的情况下，延迟特性不同。为了便于讨论，我们将图分为图9和图10，它们显示了本地回环和共享内存传输的端到端延迟的中位数。这是因为消息是否被分成几个数据包是考虑端到端延迟的导入问题。

 对于小于64 KB的数据大小，会观察到ROS2的持续开销，如图9所示，因为DDS需要对QoS策略进行编组各种配置和决策。无论数据大小如何，我们都会在延迟和QoS策略之间进行权衡。尽管QoS策略产生了不可避免的开销，但延迟是可预测的并且很小。由于ros_bridge交易，（3-b）有很大的开销。在（3-b）情况下，ros_bridge导致与ROS1和ROS2通信的开销更大。

 对于大数据，ROS2具有显着的开销，具体取决于数据的大小，如图10所示。（2-b）中ROS2的开销归因于两个因素，即DDS的数据转换和处理DDS。注意，（2-a）和（2-b）中的ROS2必须两次转换ROS2和DDS之间的消息。一次转换是从ROS2到DDS，另一种转换是从DDS到ROS2。在这些转换之间，ROS2调用DDS API并将消息传递给DDS。图11和图12显示了（2-b）OpenSplice 在reliable策略和best-effort策略中端到端延迟的细分。我们观察到ROS2仅需要转换和处理DDS。如图11和12所示，“其他”几乎没有交易。此外，请注意，数据大小会影响转换和DDS处理。与ROS1相比，DDS开销不是恒定的，并且DDS的影响在大数据时是显着的。因此，ROS2在大数据时具有显着的开销，而DDS的影响取决于QoS策略。