-
MAK
高性能的
RTI
：设计的性能
Ben Watrous
Douglas
Len Granowetter
高性能是我们的代名词
虽然对
RTI
进行评估和比较有很多标准，
但其中最
重要的就是性能。
能否选择一个吞吐
量最大，延迟性、带宽及<
/p>
CPU
的使用率最小的
RTI
，对一个
HLA
仿真应用来说意味着是否
能够成功。高性能并不是偶然发生的
—
----
只有哪些从开始阶段就本着最高性能设计，并能
够可能满足当今
HLA
联邦需求的
RTI
，
才可能做到。
这就是为什么
MAK RTI
如此独特：
以
性能为
设计目标。
在我们涉及
MAK RT
I
的设计如何导致其具有无比的性能之前，我们将讨论其
4
个主要
性能指标。
延迟
许多
分布式仿真的文献表明在不失去实时交互的情况下，
30
到
100
毫秒的延迟是可以
接受的。即使一个
运行在
60HZ
的三维图形应用，在
1
6
毫秒内计算和绘制一桢图像，
5<
/p>
到
10
毫秒的延迟可能也不会对一个特殊
事件有影响。同时即使采用
100M
的通讯网络，
MAK
RTI
的典型延迟时间都小于
250
微妙
（低于
1/4<
/p>
毫秒）
----
这足够满足大部分对实时
性敏感的
仿真系统的需求。
吞吐量
吞吐量是一个衡量
RTI
从网络读写数据快慢的标准。
从很多方面考
虑，
RTI
性能标准中
吞吐量甚至比延
迟性更为重要，
因为此指标意味者其处理拥有大量对象的联邦，
并频繁发送
更新数据的能力。在许多实时平台级仿真中，
100
到
150
字
节数据的更新和交互是相当典
型的。对于此规模的数据包，
Ma
k RTI
基于
100M
以太网实现了
每秒超过
12000
个数据包，
相当于
每秒的数据传输率超过
16Mb
。如采用捆绑方式，其性能超过
以前的两倍，即可以实
现每秒
26000
次更新。对于更大的数据包，性能会有进一步的提高。事实上，对于有效数据
为
1000
字节的数据包，
可以达到每秒钟超过
7000
个数据包的流量，
即超过
100M
网络最大
理论吞吐量的
70%
。
带宽
对于
H
LA
常见的误解就是
RTI
在带宽使用
上增加了大量的开销。
这对于某些
RTI
来说
确实如此
（特别是使用
CORB
A
的那些）
，
MAK RTI
使用的是为带宽效率设计的自定义传输
格式。其标准头仅为
8
字节，附加在每一个包的前面，所以最小的消息类型数据包只有
16
字节（如调用
publishInterac
tionClass()
）
。使用典型的
RPR
FOM
Time/Space/Position
属性更
新，其编码的数据包大小大约是
124
字节，它比
DIS Entity State
PDU
要小很多。
CPU
的占用
关于<
/p>
CPU
的占用，我们以
Mak
RTI
的代码效率而自豪，在
RTIspy GUI
图形界面上增加
了显示面板，显示每一次
RTI<
/p>
服务调用所花的时间。在一台主频为
2.4G
< br>的
PC
计算机上，
调用一次
subscribeObjectClassAttribute()
所花的平均时间为
50
微秒。加入一个联邦执行花费
60
毫秒
（大约
1/1
5
秒）
，
其中大部分的时间是从硬盘读
取
FED
文件的时间
----
而三方同
rtiexec
的握手时间小于
10
毫秒。
关于基准的看法
当然，和所有的基准
测试一样，这些都是在实验室条件下进行的：仅仅是两个联邦，
在网络上没有其他的通讯
，联邦成员除了收发数据包不做任何其他的工作，
等等。
但是，
我
们使用的是不带任何特殊网络硬件的货架
PC
计算机，采用
RTI
默认的
R
TD
设置，没有针
对测试进行特殊的设置和调试。因此这些数字
可以确切的被用作自然状态下评估的
MAK
RTI
性能。当然，最理想的是很多联邦在同样的网络拓扑结构下，同样的联邦成员，采用不
同的
RTI
进行实际的比较。第三方研究和比较多次
证实了
MAK
RTI
突出的效率和实用性。
以性能为本的设计的真正意味者什么？
早期的
RTI
执行表现了具有与高性能仿真不适应的特征。<
/p>
这些问题给
HLA
留下了这样
一个印象，
HLA
本身就比较慢，
这大大阻碍了
HLA
的采用。
因此，
当我们开始开发
MAK RTI
时，首要目标就是构建一个能够满足实时应用需求的
RTI
。直
接用
TCP
和
UDP
套接字，能
够确保数据传输通过尽可能少的软件层数。特别为
< br>MAK
RTI
设计的“传输格式”
，能够确
保数据包尽可能的紧凑。
在
MAK
RTI
的发展过程中，我们对
Time
Management, MOM, DDM
等附加服务的实现
同样采用了以性能为本的原则。
毕竟不仅仅只有飞行模拟器仿真应用才关心实时性能。<
/p>
当我
们实现这些服务的时候，我们严格遵循新功能不能影响最初子
集性能的原则。设置
RID
文
件的参数
可以允许禁止不需要的服务，
假如不需要
Time Manag
ement
或者
DDM
服务，
并且
禁止了这些服务，
那么数据传输格式将采用
不包含这些信息的传输格式。
总的来说，
附加服
务不会对延迟有较大影响，
因为自原始
RTI
发布以来，
通讯策略没有大的变化。
为此，
我们
花费了大量的精力，来保证联邦可以对就不使用的服务不付出计
算时间。例如，如果
MOM
被禁止，就没有必要收集、发送
MOM
更新所需的信息。
以性能为本
同时考虑了针对需求可能差别非常大的仿真应用的实现，因此可能会
有不
同的性能之间的折衷：
?
如果仿真必须通过
W
AN
（广域网）
或者窄带网
络连接
（例如人造卫星或者无线电）
，
那么最小化带宽使用率成为最重要的目标。
?
对于
St
ealth
这样对处理器要求很高的仿真应用，低
CPU
使用率则极为重要。
?
语音传输取决于低延迟和其可预见性。
?
对于包括大量实体的仿真应用，高
吞吐量和较少的系统调用带宽开销将是必要的。
?
最后，对于由多个参与者和联邦成
员组成的大演练，系统可伸缩性可能变为决定
因素。
在许多情况下，
MAK
RTI
提供了几个算法供用户选择，给用户自主决定如何性能折衷
的权力。尽
管大多数的联邦可以从中得到突出的性能，但
Mak
RTI<
/p>
的各种设置还是为用户
提供了高度的可配置性。
< br>例如，
使用捆绑传输可以增加网络吞吐量和最小化带宽使用率，
< br>但
要付出一些额外的
CPU
处理
时间和延迟。
此外，
MAK
RTI
为用户提供了通过
RTI Spy
插件
中应用程序接口来根据特定的联邦定制
RTI
。
HLA
是一个规范，那么和实现有什么不同？
HLA
提供了一个定义明确的应用程序接口，在某些情况中从应用程序接口到特殊实现
之间有明显的映射对应关系。但是，在
HLA
规
范里有许多方面允许各种不同的设计选择。
事实上，
这是
HLA
的目的所在
----
< br>允许各厂商构建不同性能折衷的实现来竞争，
以便让用户
选择最适合自己联邦需求的实现。
在已存在的实现中最大的区别有以下几个方面：
?
第三方网络层与自定义的传输格式
?
可靠传输实现
?
联邦成员大使回调策略
?
轻量模式的可用性
?
使用广域网的效率
?
DDM
和
Time
Managements
实现
让我们看几个
MAK RTI
开发者制
定的特定实现的选择，以及这些选择对性能的影响。
可靠传输
----TCP
Forwarder
方式
因为
TCP
协议同时仅仅支持一个接受者，
当数据
包需要通过
TCP
发送给多个接受者时，
RTI
开发者需要在两个策略中做选择。不是每一个联邦成员的
LRC
对其他每一个联邦成员
做一个连接，
< br>就是必须采用其它转发方式，
即数据包被发送给转发器，
转发器随后给其它的
所有的联邦成员发送一个副本。
下图显示了
在一个拥有
6
个成员的联邦中两种设计方式的基
本构架。
全部连接设计的
最大优点是延迟最小，因为一个数据包到达接受者仅需要一次网络传
输。但是，采用
TCP
转发器方式带来的第二次网络传输的附加延迟仅仅为一毫秒的
几分之
一。即使采用
TCP
转发器，对于可靠传输
MAK
RTI
的延迟性也能够控制在一毫秒之内。
我们将会看到，
采用转发器方式带来的额外延迟和其带来的其他优点相比，
微乎其微。
此外，
为了充分发挥
UDP
组播的优势，多数联邦通过
Best-Effort
方
式发送其大多数关键性数据，
降低延迟。
全部连接的其他优势是每次通讯传输需要最少的总传输量。
TCP
< br>转发器则需要一次从
发送者到发送给转发器的额外传输。在只有两个联邦成员的联
邦中，
TCP
转发器方式的确
需要两
倍带宽
----
每条消息需要两次传输而不是一次。
（这就是为什么
TCP
转发器方式在基
准测试比较中表现较差，因为基准测试往往只运行两个联邦成员）
。但是
，随着联邦成员数
量的增加，额外传输的附加延迟会越来越少。例如，在一个有
20
个联邦成员的联邦中，采
用
TCP
转发器
的
RTI
需要做
21
次传
输，
全连接方式的
RTI
需要
20
次传输。
MAK RTI
采用的
TCP
转发器方式相对于全连接方式有几个主要的优势。
最重要的就是