MAK RTI性能介绍

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发布以来，通讯策略没有大的变化。为此，我们花费了大量的精力，来保证联邦可以对就不使用的服务不付出计算时间。例如，如果MOM被禁止，就没有必要收集、发送MOM更新所需的信息。以性能为本同时考虑了针对需求可能差别非常大的仿真应用的实现，因此可能会有不同的性能之间的折衷：l 如果仿真必须通过WAN（广域网）或者窄带网络连接（例如人造卫星或者无线电），那么最小化带宽使用率成为最重要的目标。l 对于Stealth这样对处理器要求很高的仿真应用，低CPU使用率则极为重要。l 语音传输取决于低延迟和其可预见性。l 对于包括大量实体的仿真应用，高吞吐量和较少的系统调用带宽开销将是必要的。l 最后，对于由多个参与者和联邦成员组成的大演练，系统可伸缩性可能变为决定因素。在许多情况下，MAK RTI提供了几个算法供用户选择，给用户自主决定如何性能折衷的权力。尽管大多数的联邦可以从中得到突出的性能，但Mak RTI的各种设置还是为用户提供了高度的可配置性。例如，使用捆绑传输可以增加网络吞吐量和最小化带宽使用率，但要付出一些额外的CPU处理时间和延迟。此外，MAK RTI为用户提供了通过RTI Spy 插件中应用程序接口来根据特定的联邦定制RTI。HLA是一个规范，那么和实现有什么不同？HLA提供了一个定义明确的应用程序接口，在某些情况中从应用程序接口到特殊实现之间有明显的映射对应关系。但是，在HLA规范里有许多方面允许各种不同的设计选择。事实上，这是HLA的目的所在-允许各厂商构建不同性能折衷的实现来竞争，以便让用户选择最适合自己联邦需求的实现。在已存在的实现中最大的区别有以下几个方面：l 第三方网络层与自定义的传输格式l 可靠传输实现l 联邦成员大使回调策略l 轻量模式的可用性l 使用广域网的效率l DDM和Time Managements实现让我们看几个MAK RTI开发者制定的特定实现的选择，以及这些选择对性能的影响。可靠传输-TCP Forwarder方式因为TCP协议同时仅仅支持一个接受者，当数据包需要通过TCP发送给多个接受者时，RTI开发者需要在两个策略中做选择。不是每一个联邦成员的LRC对其他每一个联邦成员做一个连接，就是必须采用其它转发方式，即数据包被发送给转发器，转发器随后给其它的所有的联邦成员发送一个副本。下图显示了在一个拥有6个成员的联邦中两种设计方式的基本构架。全部连接设计的最大优点是延迟最小，因为一个数据包到达接受者仅需要一次网络传输。但是，采用TCP转发器方式带来的第二次网络传输的附加延迟仅仅为一毫秒的几分之一。即使采用TCP 转发器，对于可靠传输MAK RTI的延迟性也能够控制在一毫秒之内。我们将会看到，采用转发器方式带来的额外延迟和其带来的其他优点相比，微乎其微。此外，为了充分发挥UDP组播的优势，多数联邦通过Best-Effort方式发送其大多数关键性数据，降低延迟。全部连接的其他优势是每次通讯传输需要最少的总传输量。TCP转发器则需要一次从发送者到发送给转发器的额外传输。在只有两个联邦成员的联邦中，TCP 转发器方式的确需要两倍带宽-每条消息需要两次传输而不是一次。（这就是为什么TCP 转发器方式在基准测试比较中表现较差，因为基准测试往往只运行两个联邦成员）。但是，随着联邦成员数量的增加，额外传输的附加延迟会越来越少。例如，在一个有20个联邦成员的联邦中，采用TCP 转发器 的RTI需要做21次传输， 全连接方式的RTI需要20次传输。MAK RTI采用的TCP 转发器方式相对于全连接方式有几个主要的优势。最重要的就是将每个数据包发送给的多个联邦成员的CPU开销转移到一台单独的计算机上，给具体的实时应用提供了更多的计算能力。联邦成员加入联邦对其传输时间不产生影响，因为其将一个可靠消息发送给TCP 转发器。相反，采用全连接方式时，随着接收者数量的增加，联邦成员发送消息所花的CPU时间线性增加，除非每一个联邦成员都采用多处理器的计算机。当然，这将为联邦成员计算具体的应用留下较少的时间。这就是为什么采用TCP 转发器方式比全连接方式更适合大系统。随着联邦成员数量的增加，如果单一的TCP Forwarder不能满足联邦中的可靠通讯，可添加附加的TCP转发器分担传输负载。在全连接方式中不可能实现这样的负载均衡。TCP 转发器方式大大简化了联邦的网络拓朴，同时会给RTI内部带来许多好处。它简化了某些任务，如联邦成员错误冗余计算，并且极大地提高了联邦成员加入联邦的速度，因为每个LRC调用仅仅需要建立一个单一的到TCP转发器的连接。另外，也允许RTI方便地实现增加集中消息处理和数据过滤的功能。例如，转发器可以基于数据订购信息方便地过滤数据，来降低可靠通讯需要的带宽。当“Smart Forwarding”激活时MAK RTI能够完全以上描述的各种功能。最后，TCP 更适合广域网。虽然会用到多个转发器，但可以保证在每一对局域网之间仅仅发送一次数据。接受端的转发器再发给本地的每一个联邦成员。在全连接方式下，每一对联邦成员之间要有一次数据发送，这意味着一个同样的消息可能会在两个广域网之间多次发送。哪种回调策略最好？主要的RTI实现提供了三种经过联邦成员大使回调将即将接收的数据传给联邦成员的基本策略：单线程tick，完全异步回调，异步I/O tick。单线程方式是三种策略中最简单的。联邦成员从其主线程中调用RTI Ambassador tick()函数。这时RTI从网络上读取所有未处理的信息，依次调用相应的回调函数。这个方法完全避免了多线程之间的通讯开销。但是，作为这样简化的代价是联邦成员必须接受在调用tick函数时调用网络I/O的开销。另外，调用tick的联邦成员代码可能需要调试以保证网络层缓冲区不会溢出和丢失数据。在异步回调方法中，联邦成员回调通过第二个线程触发，因为数据信息已经接受到，无需等待Tick调用。异步回调方法的最大优点可能是将网络I/O的开销转移到另外的线程上，因此即使网络通讯负载很重，但联邦成员代码可以自由的执行仿真运算。对于某些应用来说，采用异步回调也提供了一个减少在回调机制中固有延迟的方法。特别是在那些应用中，联邦成员可以在其它线程中完全处理新数据，延迟可能被减少。但在大多数情况下，预期延迟会减少只是一个幻想。这是事实：如果允许发生异步回调，其可能会较早被执行。但是大多数的联邦成员设计它们的回调时，仅仅对它们收到的数据进行排队，或者将新属性值存储在对象状态数据库中供其他联邦成员代码以后访问。如果是这种情况，用异步回调将没有任何好处。比如疾驶在前面的汽车等待在红灯前一样，数据只能在联邦成员队列中或对象属性数据库内等待，直到被联邦成员最终实际使用。异步回调带来的可能的好处是以在联邦成员设计上增加复杂程度为代价的。联邦成员开发者采用异步回调必须考虑使回调线程安全。因为回调从RTI接收数据时，主仿真线程对其没有任何控制，所以必须采用锁定机制，以保证主联邦成员线程从其读取数据时，回调线程不会同时写入数据到联邦成员对象数据库。异步I/O提供了在单线程tick和多线程异步调用之间的一个折衷方法。对于异步I/O来说，RTI创建了一个单独控制网络I/O的线程。消息从网络上被读取，保存在RTI的一个队列里，当调用tick时，联邦成员可直接使用。因为该线程对于RTI来说是内部的，异步I/O可以在不用对联邦代码修改时被激活，所以联邦成员没有维持线程安全的负担。同时，提供了许多异步回调的优点：当消息到达时可以从有限的网络缓存中立即读取，这样可以大大的减少在负载很大的联邦上丢失的消息数目，并且将读取网络的开销转移出联邦成员主线程。因为异步I/O在没有增加任何额外复杂度的情况下提供了异步回调具有的大多数好处，所以在MAK RTI中使用了这种方式。同时也有采用简易单线程tick模式的能力，因为其更容易调试，需要最小的总运行开销（无需从队列中拷贝出消息和将消息拷贝到队列里）。MAK RTI提高性能的独有特性有哪些？只要符合HLA API的规定，RTI实现可任意添加针对公共联邦问题的解决方案。例如，在单个局域网上，RTI典型采用组播或者广播方式传送数据包给许多接收者。但大部分的广域网并不支持组播和广播方式。像TCP一样仅仅支持点到点的通讯。MAK RTI允许用户通过UDP 转发器最小化在广域网上使用的Best-Effort通讯。像TCP 转发器一样，UDP 转发器做为和远程局域网内所有联邦成员的唯一联系点，与其将UDP消息通过广域网发送给每个远程联邦成员，不如将其发送给UDP转发器，转发器然后在其区域网其采用组播重发消息。另外一个MAK RTI的关键特性是基于类的组播过滤解决方案。经常被描述成“穷人的DDM”，基于类的组播过滤没有任何开销，无需改写联邦成员代码，就可以提供很多DDM的优点。联邦设计者通过简单修改RID配置，就能够将FOM 类与组播地址映射起来。例如，所有的无线电通讯可以被限制在一个不同于用于实体状态数据的特殊通道。无需任何联邦成员或者RTI代码处理，在网卡层就能滤掉不必要的数据，大大减少了RTI附加在每个联邦成员上的CPU负载。当然最独特的工具是MAK RTI为最优化性能提供的RTIspy plug-in API。该API允许联邦设计者真正的打开RTI黑盒子，几乎可定制RTI的所有功能来满足联邦的特定需求。MAK怎么样帮助客户达到他们希望的性能目标呢？MAK充分认识到：仿真性能需求会越来越高，为了使我们的客户取得成功，MAK RTI必须不断发展面对挑战。根据用户的需要MAK RTI会添加更多的新功能和新的优化工具。新功能如数据包捆绑和“聪明的TCP 转发器”已经被加入到最新发布版本中，并且新的解决方案都在研发中。例如，利用RTIspy plug-in API开发的共享内存机制已经在MAK RTI中实现了，并且在不久的将来会集成到RTI内，以帮助用户充分利用多处理器机器的优点。“隐含的DDM”将允许RTI利用联邦特定的特点智能地将数据只路由给那些需要该数据的联邦成员。同时正在研发的包括其它的通讯技术，如RUDP（基于UDP的快速、可靠的协议），数据压缩技术、区别服务质量等等。附加基准信息下面是一张不同测试情况下的延迟性比较图。在所有的情况中，所有测试都运行在操作系统为XP 2.4G P4处理器，经HUB通过100M以太网连接的机器上。我们比较了原始网络和RTI的性能，该性能通过运行基于套接字、仅仅在网络上发送和接收数据的应用程序获得。从代表延迟的曲线可以看出， RTI紧紧的跟随原始网络通讯的延迟曲线，表明RTI本身没有增加多少开销。开销主要是由于RTI必须在发送数据前通过AttributeHandleValuePairSet序列化数据到网络缓存，接受数据端从序列化数据中重构AttributeHandleValuePairSet。对于可靠传输，相应的比较是在两个TCP网络之间RTI的延迟性和原始网络延迟性。虽然该指标包括了在TCP 转发器内数据包传送花费的时间，但可以看出，甚至对于较大的数据包，从末端到末端、联邦成员到联邦成员所有的可靠传输的延迟性远远低于一毫秒。对于采用TCP 转发器的RTI（比如MAK RTI）,关键在于TCP 转发器必须运行在一台专门的机器上。如果同一台机器运行一个联邦成员的同时作为TCP转发器，那么联邦成员处理会主导支配CPU，TCP 转发器会缺少CPU处理时间，造成消息阻塞。根据我们的经验，如果针对