多播通信模式下的DDS性能表现

数据分发服务(DDS)[2] 是一个面向高性能和实时系统的Object Management Group (OMG) [3]标准。DDS是一种基于发布-订阅通信模式的数据中心中间件,广泛应用于许多任务关键性甚至安全关键性系统,例如空中交通控制和机器人操作系统(ROS2)。

这项研究旨在确定多播使用如何影响DDS通信在不同数量的参与者(发布者和订阅者)下的性能。结果表明,配置为多播通信的DDS在高负载(更多的参与者)下的表现可能比配置为单播通信的DDS更差。这一违反直觉的结果强调了研究人员和实践者需要清楚地了解多播通信在网络上的运行细节的必要性。

INTRODUCTION

DDS是由OMG发布的面向高性能、实时和可扩展系统的中间件标准。该标准遵循发布-订阅通信模式,被用于各种需要实时通信的应用程序,例如空中交通控制、机器人技术、自动驾驶汽车等。在DDS中,参与者-发布者和订阅者-通过一个或多个信息(称为主题)相互通信。DDS规范定义了22个服务质量(QoS)参数,用于自定义通信,例如可靠性(Reliability),它控制发布者在发布下一个数据样本之前是否等待订阅者的确认- 可靠通信(或相反的“尽力而为”通信)。还有非QoS参数用于自定义通信,例如使用单播或多播通信。单播通信定义一个主机每次只向另一个主机发送数据,而多播则建立了一对多的通信,使单个主机可以在单次通信中向多个主机发送数据。

PROBLEM DEFINITION

尽管单播或多播通信未在DDS规范中定义,但其在DDS内部消息通信中的使用仍起着至关重要的作用。对于对多播实现细节了解有限的DDS用户而言,他们可能认为在参与者数量更多时,多播传输理论上应该优于单播,因为数据只需通过一次通信发送而不是多次。然而,在实践中,这种情况不一定成立—。我们在论文中探讨了这种反直觉的现象。

多播路由协议(MRP)在不同的设置中可能会有所不同,这可能会影响性能。基本上,MRP从发送者到接收者组创建最短路径树(SPT)。有两种类型的SPT,性能取决于网络结构以及创建的SPT类型。

本研究重点研究多播对DDS性能在不同参与者数量下的影响。通过本研究产生的结果,我们可以确定,尽管在大量参与者的情况下使用多播是直观的,但是应该清楚地了解

实验设置

这项性能测试的实验设置包括四个运行CentOS 7.9-2009的虚拟机,每个虚拟机都有8GB的RAM和500GB的硬盘空间。在性能测试中,使用了由Real-Time Innovations (RTI)[6]提供的PerfTest[5]工具,该工具允许使用两种类型的测试:延迟测试或吞吐量测试。本文使用后者,尽管两种类型的测试都可以测量延迟和吞吐量。吞吐量测试始于特定的发布者(发布者0)发送一个延迟测量数据包并等待其响应,然后发送一个用户定义数量的吞吐量数据包到订阅者以模拟DDS系统在实际应用中的使用情况。一旦传输了这个吞吐量数据包的数量,发布者将重复这个过程(通过发送另一个延迟测量数据包)。

图1

2-way延迟在发布者0上测量,吞吐量通过每个订阅者记录其随时间接收的样本来测量。因此,在我们的测量中,我们聚合了每个时间单位内所有订阅者的吞吐量,以公平地比较每个测试的吞吐量测量结果。图1, 简要说明了每种测试类型的数据包传输方式。在实验中,数据长度、测试持续时间、可靠性、参与者数量和通信类型的值都被改变。表1显示了每个参与者使用的设置。我们平均分配参与者以保证公平的通信负载。

表1

Setting

Value

Data Length

100 Bytes

Test Duration

6 Hours

Latency Count

1000

Reliability

reliable

Number of Publishers

1, 3, 10, 25, 50, 75

Number of Subscribers

1, 3, 10, 25, 50, 75

本文的测试是我们对DDS性能全面评估的一部分,该评估受到AQUAS项目[1]中的航空交通管制场景的启发,该场景使用了各种数量的无人机,从个位数到两位数不等 - 一个真实的应用场景。这些具体测试产生了奇怪的结果,从而导致本文的产生。

“Latency Count”设置定义了每个延迟测量包之间传输多少吞吐量包。由于在需要数据传输得到确认的关键系统中可靠性被期望使用,因此“可靠性”设置被设置为可靠。

EXPERIMENTAL RESULTS

图2展示了每个测试的延迟测量的实验累积分布函数(ECDF),图3显示了吞吐量测量的ECDF。如果查看图2左上角的ECDF,则可以将点(0.25,0.8)解释为“80%的延迟测量值小于或等于0.25毫秒”。本文中使用以下缩写:“ms”- 毫秒,“$mu$s”- 微秒和“mbps”- 每秒兆位数。


图2


Latency Results

在测试中,即使分布函数几乎相同,单播通信的延迟值仍低于多播通信。单播和多播的延迟均值都为0.22毫秒。在涉及3个发布者和3个订阅者的测试中,单播通信值的平均值为0.56毫秒,而多播通信值的平均值为0.62毫秒,增加了11%。在涉及10个发布者和10个订阅者的测试中,排名反转:平均单播延迟为3.6毫秒,而平均多播延迟为3.2毫秒,降低了11%。尽管以前的测试结果清楚地显示了随机排序(ECDF上的曲线之间没有交叉点)在两种通信类型之间,但25个发布者和25个订阅者的测试没有显示。单播通信包含更多的0ms到10ms之间的值以及35ms以上的值,而多播通信的结果包含更多的10ms到35ms之间的值。

下一个测试包括50个发布者和50个订阅者,延续了单播通信显示随机优势的模式,其中分布函数显示多播通信始终产生更高的延迟。单播通信的延迟平均值为8.3毫秒,而多播通信的延迟平均值为12.5毫秒,增加了51%。在最后一个测试中,涉及75个发布者和75个订阅者,分布函数显示单播通信的延迟值始终更低(平均为312毫秒),而多播通信的延迟值更高(平均为427毫秒),增加了37%。

总之,单播通信在涉及1个发布者和1个订阅者、3个发布者和3个订阅者、50个发布者和50个订阅者以及75个发布者和75个订阅者的测试中产生更好的延迟值。在6个测试中,有4个测试得出结论,单播设置产生更低的延迟测量值。只有1个测试(涉及10个发布者和10个订阅者)产生更好的多播延迟结果。涉及25个发布者和25个订阅者的测试是唯一一个产生结果,其中两种设置都没有一致占优的情况。

Throughput Results

在图3中,1个发布者和1个订阅者的测试显示大约有10%的吞吐量测量值几乎相同。对于大于85mbps的吞吐量测量值,单播通信始终产生更高的吞吐量值。在3个发布者和3个订阅者的测试中,没有任何一种通信设置是支配性的。单播通信有更高比例的值高达125mbps,而多播通信产生更高比例的值在125mbps和145mbps之间。单播通信测量结果包含更多在145mbps到170mbps之间的值,而多播通信测量结果包含更多在170mbps到185mbps之间的值。对于大于185mbps的值,单播通信具有更高的百分比。


图3


在10个发布者和10个订阅者的测试中,ECDF显示多播通信产生更大的吞吐量。单播通信的平均吞吐量值为237mbps,而多播通信的平均吞吐量值为292mbps - 增加了23%。25个发布者和25个订阅者的测试结果也没有显示明显的差异:多播通信在生产高达190mbps的更高百分比值之前产生了更高的百分比值,然后这种观察结果反转,单播通信在高达220mbps的更高百分比值之前产生了更高的百分比值。单播吞吐量的最大值为217mbps,而多播吞吐量的最大值为260mbps。

从“50个发布者/50个订阅者”的测试结果产生的结果表明,多播通信始终产生比单播通信更低的吞吐量。单播测量的均值为179mbps,而多播测量的均值为169mbps - 减少了6%。75个发布者和75个订阅者的测试显示出类似的模式,其中多播结果产生的吞吐量测量值始终比单播通信低。单播吞吐量均值为175mbps,而多播均值为160mbps - 减少了9%。

总的来说,在单个发布者和单个订阅者、50个发布者和50个订阅者以及75个发布者和75个订阅者的测试中,单播通信的吞吐量值更好。而在10个发布者和10个订阅者以及大部分25个发布者和25个订阅者的测试中,多播通信的吞吐量值更好。在6个测试中,单播通信在3个测试中产生了更优秀的测量值,而多播通信在2个测试中产生了更优秀的吞吐量值。只有在3个发布者和3个订阅者的测试中,没有观察到一致的排序。

Discussion

从理论上讲,当大量参与者使用多播通信时,所有接收者的数据都使用一个通信发送,而不是像单播通信一样使用多个 - 这应该会导致多播在大量参与者情况下的性能更好。然而我们的实验结果表明了相反的情况。在表2中展示了最佳通信方式的摘要。经过调查,我们猜测使用DDS的多播通信所获得的性能在很大程度上取决于网络设置,具体来说,取决于使用的多播路由协议。为了确认这一点,我们计划进一步实验并改变网络结构以模拟现实应用,同时研究多播通信的效果。本工作的主要观点是,在将多播通信用于DDS部署之前,必须对实验环境中如何实现多播通信有全面的了解。不应假定通过DDS实现的多播通信与大量参与者一起使用一定会导致更好的性能。

表2


Latency

Throughput

1P + 1S

unicast

unicast

3P + 3S

unicast

mixe

10P + 10S

multicast

multicast

25P + 25S

mixed

multicast

50P + 50S

unicast

unicast

75P + 75S

unicast

unicast

Related Work

虽然许多论文已经评估了DDS在不同设置下的性能,但只有少数论文关注了多播。

在[7]]中进行了研究,当使用8个发布者和6个订阅者时,对“Best Effort”可靠性设置进行了实验。结果显示,单播的平均延迟为243$mu$s,而多播的平均延迟为270$mu$s。另一篇论文[8]调查了不同的数据长度,在1个发布者和1个订阅者的情况下,128字节的数据长度的单播平均延迟大于多播的平均延迟(接近我们实验中使用的100字节)。在吞吐量方面,单播和多播通信几乎相同,平均单播吞吐量略高。在1个发布者和7个订阅者的情况下,平均多播吞吐量大约是平均单播吞吐量的四倍,平均单播延迟显着更大。

在[9]中,实验集中在1个发布者和4个和12个订阅者的变化(以及不同的数据长度)。在4个订阅者的情况下,单播吞吐量与组播吞吐量几乎相同,后者略低。在12个订阅者的测试中,吞吐量测量的差异要大得多:组播吞吐量要大。在[10]中,作者在不同的数据长度下使用了4个发布者和3个订阅者进行了实验。当使用128字节数据包时,单播的平均延迟为300微秒,而组播的平均延迟为350微秒。

本节提到的所有文献都与本研究所得到的测量值有很大差异。我们怀疑这可能是由于我们实验中使用的虚拟化技术造成的。

Conclusion

本文使用 RTI Perftest 在不同参与者数量下探究了多播通信对 DDS 实现的影响。实验结果呈现出一种出人意料的现象:当使用大量参与者时,单播通信的性能优于多播通信。

我们推测,多播性能在根本上取决于网络设置,特别是使用的多播路由协议。因此,对于某些测试类型,多播性能较差并不是由于 DDS 协议或特定的 DDS 实现。因此,本文的研究结果鼓励我们进一步研究多播通信与 DDS 的详细工作原理,以及改变该通信的各个方面可能会对性能产生的影响。我们计划在不同网络设置下运行进一步的实验,包括使用不同的多播协议以及变化 DDS 相关设置,例如在不同写入/读取负载下使用不同的数据长度以研究多播通信的效果,并评估其他 DDS 实现上的多播通信。我们还计划探索虚拟化对多播通信性能的影响。

引用

展开阅读全文

页面更新:2024-05-01

标签:性能   通信   吞吐量   参与者   发布者   测量   平均   数量   测试   数据

1 2 3 4 5

上滑加载更多 ↓
推荐阅读:
友情链接:
更多:

本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828  

© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号

Top