面向虛擬仿真環境的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.