2020年新版MAKRTI性能介绍.docxVIP

MAK高性能的RTI :设计的性能 Ben Watrous Douglas D.Wood Len Grano wetter 咼性能是我们的代名词 虽然对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 字节（如调用 publishlnteractionClass（））。使用典型的 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服务，并且 禁止了这些服务，那么数据传输格式将采用不包含这些信息的传输格式。 总的来说，附加服