面向虚拟仿真环境的BH RTI性能测试研究

李 静

(山西太钢不锈钢股份有限公司营销部，山西 太原 030003)

0 引言

HLA(高层体系架构，High Level Architecture)是由美国国防建模与仿真办公室(DMSO)提出的一个通用建模与仿真的共同技术框架，在该体系架构下，系统不同层次对象模型的设计、开发和实现采用面向对象(Object－Oriented)的方法。为了适应分布式交互式仿真应用对仿真技术要求的不断提高，分布式交互仿真技术不断发展，在总结和改进各种分布式交互仿真技术的基础上，DMSO提出了HLA仿真框架，这使得现代仿真应用程序对重用性、扩展性和互操作性的要求在HLA仿真框架下都能很好地实现。［1］

在基于 HLA的分布式仿真环境中，RTI(Run-Time Infrastructure)是仿真系统运行的核心支撑软件，它的性能和功能直接影响到基于其开发和运行的仿真系统。在决定采用某种RTI进行应用程序开发之前，需要对RTI的性能进行充分的论证，其中，对RTI进行性能测试是保证后期软件开发质量的重要步骤。由于DMSO和IEEE1516的技术标准只对体系结构进行了规范，而对RTI具体的技术实现没有明确规定［2］，因而目前各种RTI在满足HLA框架结构的基础上，可以采用独特的方式进行实现。为此，软件开发前期，针对RTI的性能测试就显得十分重要。本文对BH－RTI的时间同步、网络延迟、吞吐量等性能指标进行了研究测试，测试结果为后续的软件开发提供了可信的依据。

1 RTI性能测试分析

RTI是在HLA仿真框架的具体实现，它按照HLA的接口规范标准进行开发［2］，为分布式仿真应用程序提供统一的用于仿真交互的开发服务接口，并为应用程序提供运行环境。下面分别对RTI的时间同步、网络延迟和吞吐量三方面的性能测试进行研究。

1.1 时间同步测试分析

在分布式交互仿真应用程序开发中，事件的一致性是一项基本要求。在分布式交互系统中，节点的分布比较分散，通过网络系统，节点之间进行信息交换。目前，数据在网络上进行传输时，会因为网络结构的不同而有所延迟。此外，各个节点的物理配置各不相同，因而对数据处理的能力也不尽相同，造成各节点处理数据的速度各不相同。以上原因，均会对事件推进的一致性带来不能预测的结果。为了保证仿真系统运行在统一的时间刻度，需采用特殊方法以保证对时间进行同步。

仿真系统中，对于时间管理采取的方法多种多样，其中比较早的是并行离散事件仿真PDES(Parallel Discrete Event Simulation)，对仿真时间的一致性采用并行处理的方式。随后出现的Lamport算法，对节点间因果事件的一致性采用时间戳的处理方式。向量时钟方法的基础是Lam-port算法，并在其上进行了节点扩展，可以对更多节的因果性事件进行一致性处理，但不能保证其对并发事件产生与处理的一致性［3］。HLA标准采用了时间推进区间法，在PDES基础上进行扩展，并通过网络传输对时间推进进行比较有效的管理。

在基于HLA开发的仿真应用运行过程中，各节点之间通过相互发送时间报文来协调推进事件的同步。对于可靠性要求高的报文，则采用IP单播的网络通讯方式以保证可靠的报文传输，而采用IP组播的方式可以保证高效的报文传输，有效地降低对带宽的资源消耗，提高数据报文的传输效率。在基于分组管理的LBTS(Lower Bound Time Stamp)计算模型中，各节点之间的同步协调采用时间同步控制报文。

1.2 网络延迟测试分析

在分布式仿真系统中，为了保证仿真系统能合理推进，对各节点的属性进行可靠的更新是RTI首先要完成的任务。为此，在RTI中设计开发了其它服务，以保证各节点能以一定的顺序，在特点的时间点投递联邦成员的属性更新报文，并保证更新报文传递到对其感兴趣的联邦成员。因此，对属性更新延迟进行测量，是衡量RTI性能的关键指标之一。

RTI的具体实现可以采用多种方式，不同的RTI有不同的体系架构，而采用何种体系架将对RTI的网络延迟产生关键影响。一般的RTI体系架构有分布式、层次式和集中式三种。采用集中式体系架构的RTI，在中心节点上实现所有服务，中心节点是计算和通信的瓶颈;采用分布式体系架构的RTI使用LRC对时间进行推进，需要更多的资源对任务进行处理和协调，运行效率不高;层次式体系结构的RTI采用分层结构，具有前述两种体系架构的优点，根据各节点请求的不同，分别采用集中处理或节点间直接通讯的方式进行报文投递，有效地在效率和可靠性之间进行了平衡，也利于布置规模更大的仿真系统。

由于节点间通过网络进行通信，节点所在网络类型可能各不相同。报文在传递过程中需要对其进行转换和处理，不同的报文处理和投递方式是影响性能的另一重要因素。在基于RTI的分布式仿真系统中，节点间传递的消息有数据类消息和控制类消息两类。控制类消息包含的是节点间关键的控制消息，需要采用可靠的点对点IP单播通讯方式;对于数据类消息，有关键数据和广播数据之分，可分别对其采用单播或组播方式。由于层次式模型的特点，LRC(本地RTC组件)之间及LRC与CRC(核心RTI组件)之间根据不同的需求，可以采用通过CRC转发消息方式或是任两个LRC间都直接建立连接的方式。直接连接的方式可以获得良好的实时性能，但在节点数目较多的情况下，占用资源十分巨大。

1.3 吞吐量测试分析

吞吐量是能从总体反映系统对数据处理能力的指标。在规模较大的分布式仿真系统中，节点成员较多，在系统中投递的报文数据量十分可观。系统在单位时间内能够处理的报文数量(吞吐量)是反映系统性能的重要指标。在报文发送能力和报文接收能力两者之中，使用每秒能处理的最小平均速率来表示系统的属性吞吐量。

在分布式仿真应用中，位于不同物理位置的节点通过网络进行信息交换。为了提高系统整体运行效率，减少对网络带宽的消耗，在RTI的各种实现中采用了不同的数据分发机制。在数据分发机制中，各发送数据的联邦成员会在发送的报文中包含数据适用的范围，接收报文的联邦成员在加入联邦时，会向系统声明所需接收的数据类型，当两者匹配时，RTI才会通过网络在相应的范围内投递数据，从而减少了对带宽资源的消耗。

2 BH RTI性能测试方案设计

2.1 概述

本文设计的分布式仿真性能测试系统运行在100M以太网环境中，采用TCP/IP协议进行通信，各节点计算机使用WINDOWS XP操作系统。节点间的网络通信基于BH RTI分布式仿真运行平台。测试方案的目的是考核BH RTI分布式仿真平台的运行效率，测试系统使用VC++2005在BH RTI提供的接口基础之上进行开发。性能测试网络拓扑结构图如图1所示。

BH RTI性能测试网络拓扑图说明:

(1)中间的服务器上运行的是BH RTI Central Server，其上运行BH RTI管理服务，减少了大规模分布式仿真中进行全局一致性操作所占用的大量网络带宽，有利于进一步扩大仿真应用规模。

(2)各节点运行BH RTI 2.3软件，同时还运行基于BH RTI 2.3开发的测试软件。测试软件可以选择数据通信方式(一对一或一对多)、数据量大小和数据发送频率。测试系统中每节点发送的数据量从32Byte～4KByte之间可调，发送频率从10ms～10s之间可调。当节点间采用一对多方式进行通信时，采用组播方式，以节省网络带宽。

2.2 BH RTI 2.3性能测试指标及测试结果

本文对BH RTI 2.3在时间推进、属性更新延迟和吞吐量三个方面的性能指标进行了测试。

(1)时间推进请求响应测试:主要测试推进一个事件所消耗的时间。编写测试程序时需要对属性的更新次数、更新的属性数据量、采用的数据投递机制(Reliable or Best Effort)、发送失败时重新请求的次数进行考虑。考虑使用两个联邦成员参与测试，运行测试程序，让参与测试的成员尽最大可能发出时间推进请求，运行一段时间后，计算在单位时间内平均推进的次数。

图1 BH RTI性能测试网络拓扑图

在如图1所示的网络环境中，测试的结果如下:

Cycle:1 Grants/sec:835.31 Cycle:2 Grants/sec:1481 Cycle:3 Grants/sec:1221.45 Cycle:4 Grants/sec:1448.22 Cycle:5 Grants/sec:1472.83 Cycle:6 Grants/sec:762.715 Cycle:7 Grants/sec:1733.36 Cycle:8 Grants/sec:1250.1 Cycle:9 Grants/sec:782.97 Cycle:10 Grants/sec:835.2

时间推进进行了10次循环，每次循环以每秒所有盟员推进的次数为单位。从结果来看，BH RTI 2.3在具有10台主机节点的环境中，每秒推进的次数在1000次左右。

(2)更新延迟测试:参与测试的两个联邦成员在程序中采用“Ping－Pong”的发送方式进行属性更新。编写测试程序时需要对对属性的更新次数、更新的属性数据量、采用的数据投递机制(Reliable or Best Effort)、发送失败时重新请求的次数进行考虑。设两个联邦成员分别为甲和乙。成员甲首先发出更新请求，RTI将成员甲的属性更新反射给成员乙，成员乙收到请求后立刻发出一个新的属性更新请求，RTI将成员乙的属性更新反射给成员甲，成员甲收到后同样再发出一个新的属性更新请求，测试程序运动一段时间后，计算每次属性更新的所消耗的时间，即是属性更新延迟时间。

在如图1所示的网络环境中，测试的结果如下:

＞message length:32 latency is 0.328260 ms latency is 0.358028 ms latency is 0.515396 ms latency is 0.800453 ms latency is 0.079524 ms latency is 1.450499 ms latency is 2.236760 ms latency is 3.595458 ms latency is 0.602948 ms latency is 0.486451 ms＞message length:256 latency is 0.120207 ms latency is 0.452280 ms latency is 0.026911 ms latency is 1.084144 ms latency is 0.237764 ms latency is 0.954244 ms latency is 0.339799 ms latency is 0.253861 ms latency is 1.702599 ms latency is 1.213818 ms

属性的更新延迟测试时发送的数据包大小分为32字节、256字节，分别循环10次。从测试结果看，延迟时间都在毫秒级。

(3)吞吐量测试:系统吞吐量能从总体反映系统对数据的处理能力。编写测试程序时需要对对属性的更新次数、更新的属性数据量、采用的数据投递机制(Reliable or Best Effort)、发送失败时重新请求的次数进行考虑。对于发送属性的联邦成员，更新吞吐量由单位时间内发出UAV(Update Attribute Value)调用的次数决定。对于接收属性更新的联邦成员，反射属性吞吐量由单位时间接收到RAV(Reflect Attribute Values)调用的次数而决定，两者之中的最小值即为系统的吞吐量。

在设计测试程序时，需要注意的是，在反射属性回调函数中的代码应尽量精减。在测试结果中需要记录查找函数的时间复杂性和查找的对象数目。

测试的结果反映平均更新属性值速率、平均反射属性值速率和平均发送交互速率、平均接受交互速率［4］。在如图1所示的网络环境中，测试的结果如下:

32个字节时每秒更新属性值次数type the pdu length:32＞message length 32 UAV:7350.15/s UAV:7123.62/s UAV:7745.10/s UAV:8546.48/s UAV:8457.50/s UAV:7707.57/s UAV:8413.30/s UAV:8412.33/s UAV:7744.32/s UAV:7681.35/s与之对应的反射属性吞吐量:message length:32，RAV 7215.10/s message length:32，RAV 6997.43/s message length:32，RAV 6777.67/s message length:32，RAV 8521.18/s message length:32，RAV 8357.86/s message length:32，RAV 7958.48/s message length:32，RAV 8179.35/s message length:32，RAV 9059.92/s message length:32，RAV 7222.78/s message length:32，RAV 7639.28/s 256个字节时每秒更新属性值次数type the pdu length:256＞message length 256 UAV:8076.11/s UAV:7862.32/s UAV:7769.82/s UAV:7620.86/s UAV:7735.42/s UAV:7858.71/s UAV:7244.56/s UAV:7882.26/s UAV:7863.21/s UAV:7911.10/s message length:256，RAV 7139.96/s message length:256，RAV 7975.90/s message length:256，RAV 8196.80/s message length:256，RAV 7248.66/s message length:256，RAV 7727.12/s message length:256，RAV 7927.99/s message length:256，RAV 7843.50/s message length:256，RAV 7265.51/s message length:256，RAV 7867.53/s message length:256，RAV 7783.18/s

由于BH RTI 2.3采用了MCTS(Multi－node Coordination Time Synchronization)算法，根据时间控制报文可靠性定理引入IP组播来处理控制报文的传输，提高了节点的处理效率，大大降低了报文的带宽开销，提高了系统的处理能力。

3 结论

本文通过对RTI理论的学习研究，设计了对BH RTI进行性能测试的方案，分别对BH RTI的时间同步，网络延迟和吞吐量三方面编写了性能测试程序。性能测试的结果表明BH RTI的时间同步性能很好，BH RTI 2.3在10台主机连接时，每秒推进的次在1000次左右，网络延迟比较低，属性更新延迟都在毫秒级，满足后续项目对性能指标的要求。

［1］Defense Modeling and Simulation Office.High Level Architecture Interface Specification，v1.3［EB/OL］.(1998 － 02 －05).http://hla.dmso.mil/hla/tech/ifspec/if1 －3d9b.doc.

［2］Defense Modeling and Simulation Office.High Level Architecture Rules，v1.3［EB/OL］.(1998 － 02 － 05).5 February 1998，http://hla.dmso.mil/hla/tech/rules/rules1 －3d2b.doc.

［3］周忠，赵沁平.基于兴趣层次的RTI拥塞控制研究［J］.软件学报，2004，15(1):120 －130.

［4］Algorithm of Simulation Time Synchronization over Largescale Nodes Zhao Qin-ping，Zhou Zhong，lv fang，Science in China Series F-Information Sciences，2008，51(9):1239 －1255.