MAKRTI性能介绍.doc

MAK高性能的RTI：设计的性能 Ben Watrous Douglas D.Wood Len Granowetter 高性能是我们的代名词 虽然对RTI进行评估和比较有很多标准，但其中最重要的就是性能。能否选择一个吞吐量最大，延迟性、带宽及CPU的使用率最小的RTI，对一个HLA仿真应用来说意味着是否能够成功。高性能并不是偶然发生的—----只有哪些从开始阶段就本着最高性能设计，并能够可能满足当今HLA联邦需求的RTI，才可能做到。这就是为什么MAK RTI如此独特：以性能为设计目标。 在我们涉及MAK RTI的设计如何导致其具有无比的性能之前，我们将讨论其4个主要性能指标。 延迟 许多分布式仿真的文献表明在不失去实时交互的情况下，30到100毫秒的延迟是可以接受的。即使一个运行在60HZ的三维图形应用，在16毫秒内计算和绘制一桢图像， 5到10毫秒的延迟可能也不会对一个特殊事件有影响。同时即使采用100M的通讯网络，MAK RTI的典型延迟时间都小于250微妙（低于1/4毫秒）----这足够满足大部分对实时性敏感的仿真系统的需求。 吞吐量 吞吐量是一个衡量RTI从网络读写数据快慢的标准。从很多方面考虑，RTI性能标准中吞吐量甚至比延迟性更为重要，因为此指标意味者其处理拥有大量对象的联邦，并频繁发送更新数据的能力。在许多实时平台级仿真中， 100到150字节数据的更新和交互是相当典型的。对于此规模的数据包，Mak RTI基于100M以太网实现了每秒超过12000个数据包，相当于每秒的数据传输率超过16Mb。如采用捆绑方式，其性能超过以前的两倍，即可以实现每秒26000次更新。对于更大的数据包，性能会有进一步的提高。事实上，对于有效数据为1000字节的数据包，可以达到每秒钟超过7000个数据包的流量，即超过100M网络最大理论吞吐量的70%。 带宽 对于HLA常见的误解就是RTI在带宽使用上增加了大量的开销。这对于某些RTI来说确实如此（特别是使用CORBA的那些），MAK RTI使用的是为带宽效率设计的自定义传输格式。其标准头仅为8字节，附加在每一个包的前面，所以最小的消息类型数据包只有16字节（如调用publishInteractionClass()）。使用典型的RPR FOM Time/Space/Position属性更新，其编码的数据包大小大约是124字节，它比DIS Entity State PDU要小很多。 CPU的占用 关于CPU的占用，我们以Mak RTI的代码效率而自豪，在RTIspy GUI图形界面上增加了显示面板，显示每一次RTI服务调用所花的时间。在一台主频为2.4G 的PC计算机上，调用一次subscribeObjectClassAttribute()所花的平均时间为50微秒。加入一个联邦执行花费60毫秒（大约1/15秒），其中大部分的时间是从硬盘读取FED文件的时间----而三方同rtiexec的握手时间小于10毫秒。 关于基准的看法 当然，和所有的基准测试一样，这些都是在实验室条件下进行的：仅仅是两个联邦，在网络上没有其他的通讯，联邦成员除了收发数据包不做任何其他的工作，等等。但是，我们使用的是不带任何特殊网络硬件的货架PC计算机，采用RTI默认的RTD设置，没有针对测试进行特殊的设置和调试。因此这些数字可以确切的被用作自然状态下评估的MAK RTI性能。当然，最理想的是很多联邦在同样的网络拓扑结构下，同样的联邦成员，采用不同的RTI进行实际的比较。第三方研究和比较多次证实了MAK RTI突出的效率和实用性。 以性能为本的设计的真正意味者什么？ 早期的RTI执行表现了具有与高性能仿真不适应的特征。这些问题给HLA留下了这样一个印象，HLA本身就比较慢，这大大阻碍了HLA的采用。因此，当我们开始开发MAK RTI时，首要目标就是构建一个能够满足实时应用需求的RTI。直接用TCP和UDP 套接字，能够确保数据传输通过尽可能少的软件层数。特别为MAK RTI设计的“传输格式”，能够确保数据包尽可能的紧凑。 在MAK RTI的发展过程中，我们对Time Management, MOM, DDM等附加服务的实现同样采用了以性能为本的原则。毕竟不仅仅只有飞行模拟器仿真应用才关心实时性能。当我们实现这些服务的时候，我们严格遵循新功能不能影响最初子集性能的原则。设置RID文件的参数可以允许禁止不需要的服务，假如不需要Time Management或者DDM服务，并且禁止了这些服务，那么数据传输格式将采用不包含这些信息的传输格式。总的来说，附加服务不会对延迟有较大影响，因为自原始RTI发布以来，通讯策略没有大的变化。为此，我们花费了大量的精力，来保证联邦可以对就不使用的服