面向虛擬仿真環(huán)境的BH RTI性能測試研究

李 靜

(山西太鋼不銹鋼股份有限公司營銷部，山西 太原 030003)

0 引言

HLA(高層體系架構(gòu)，High Level Architecture)是由美國國防建模與仿真辦公室(DMSO)提出的一個通用建模與仿真的共同技術(shù)框架，在該體系架構(gòu)下，系統(tǒng)不同層次對象模型的設(shè)計、開發(fā)和實現(xiàn)采用面向?qū)ο?Object－Oriented)的方法。為了適應(yīng)分布式交互式仿真應(yīng)用對仿真技術(shù)要求的不斷提高，分布式交互仿真技術(shù)不斷發(fā)展，在總結(jié)和改進各種分布式交互仿真技術(shù)的基礎(chǔ)上，DMSO提出了HLA仿真框架，這使得現(xiàn)代仿真應(yīng)用程序?qū)χ赜眯浴U展性和互操作性的要求在HLA仿真框架下都能很好地實現(xiàn)。［1］

在基于 HLA的分布式仿真環(huán)境中，RTI(Run-Time Infrastructure)是仿真系統(tǒng)運行的核心支撐軟件，它的性能和功能直接影響到基于其開發(fā)和運行的仿真系統(tǒng)。在決定采用某種RTI進行應(yīng)用程序開發(fā)之前，需要對RTI的性能進行充分的論證，其中，對RTI進行性能測試是保證后期軟件開發(fā)質(zhì)量的重要步驟。由于DMSO和IEEE1516的技術(shù)標(biāo)準(zhǔn)只對體系結(jié)構(gòu)進行了規(guī)范，而對RTI具體的技術(shù)實現(xiàn)沒有明確規(guī)定［2］，因而目前各種RTI在滿足HLA框架結(jié)構(gòu)的基礎(chǔ)上，可以采用獨特的方式進行實現(xiàn)。為此，軟件開發(fā)前期，針對RTI的性能測試就顯得十分重要。本文對BH－RTI的時間同步、網(wǎng)絡(luò)延遲、吞吐量等性能指標(biāo)進行了研究測試，測試結(jié)果為后續(xù)的軟件開發(fā)提供了可信的依據(jù)。

1 RTI性能測試分析

RTI是在HLA仿真框架的具體實現(xiàn)，它按照HLA的接口規(guī)范標(biāo)準(zhǔn)進行開發(fā)［2］，為分布式仿真應(yīng)用程序提供統(tǒng)一的用于仿真交互的開發(fā)服務(wù)接口，并為應(yīng)用程序提供運行環(huán)境。下面分別對RTI的時間同步、網(wǎng)絡(luò)延遲和吞吐量三方面的性能測試進行研究。

1.1 時間同步測試分析

在分布式交互仿真應(yīng)用程序開發(fā)中，事件的一致性是一項基本要求。在分布式交互系統(tǒng)中，節(jié)點的分布比較分散，通過網(wǎng)絡(luò)系統(tǒng)，節(jié)點之間進行信息交換。目前，數(shù)據(jù)在網(wǎng)絡(luò)上進行傳輸時，會因為網(wǎng)絡(luò)結(jié)構(gòu)的不同而有所延遲。此外，各個節(jié)點的物理配置各不相同，因而對數(shù)據(jù)處理的能力也不盡相同，造成各節(jié)點處理數(shù)據(jù)的速度各不相同。以上原因，均會對事件推進的一致性帶來不能預(yù)測的結(jié)果。為了保證仿真系統(tǒng)運行在統(tǒng)一的時間刻度，需采用特殊方法以保證對時間進行同步。

仿真系統(tǒng)中，對于時間管理采取的方法多種多樣，其中比較早的是并行離散事件仿真PDES(Parallel Discrete Event Simulation)，對仿真時間的一致性采用并行處理的方式。隨后出現(xiàn)的Lamport算法，對節(jié)點間因果事件的一致性采用時間戳的處理方式。向量時鐘方法的基礎(chǔ)是Lam-port算法，并在其上進行了節(jié)點擴展，可以對更多節(jié)的因果性事件進行一致性處理，但不能保證其對并發(fā)事件產(chǎn)生與處理的一致性［3］。HLA標(biāo)準(zhǔn)采用了時間推進區(qū)間法，在PDES基礎(chǔ)上進行擴展，并通過網(wǎng)絡(luò)傳輸對時間推進進行比較有效的管理。

在基于HLA開發(fā)的仿真應(yīng)用運行過程中，各節(jié)點之間通過相互發(fā)送時間報文來協(xié)調(diào)推進事件的同步。對于可靠性要求高的報文，則采用IP單播的網(wǎng)絡(luò)通訊方式以保證可靠的報文傳輸，而采用IP組播的方式可以保證高效的報文傳輸，有效地降低對帶寬的資源消耗，提高數(shù)據(jù)報文的傳輸效率。在基于分組管理的LBTS(Lower Bound Time Stamp)計算模型中，各節(jié)點之間的同步協(xié)調(diào)采用時間同步控制報文。

1.2 網(wǎng)絡(luò)延遲測試分析

在分布式仿真系統(tǒng)中，為了保證仿真系統(tǒng)能合理推進，對各節(jié)點的屬性進行可靠的更新是RTI首先要完成的任務(wù)。為此，在RTI中設(shè)計開發(fā)了其它服務(wù)，以保證各節(jié)點能以一定的順序，在特點的時間點投遞聯(lián)邦成員的屬性更新報文，并保證更新報文傳遞到對其感興趣的聯(lián)邦成員。因此，對屬性更新延遲進行測量，是衡量RTI性能的關(guān)鍵指標(biāo)之一。

RTI的具體實現(xiàn)可以采用多種方式，不同的RTI有不同的體系架構(gòu)，而采用何種體系架將對RTI的網(wǎng)絡(luò)延遲產(chǎn)生關(guān)鍵影響。一般的RTI體系架構(gòu)有分布式、層次式和集中式三種。采用集中式體系架構(gòu)的RTI，在中心節(jié)點上實現(xiàn)所有服務(wù)，中心節(jié)點是計算和通信的瓶頸;采用分布式體系架構(gòu)的RTI使用LRC對時間進行推進，需要更多的資源對任務(wù)進行處理和協(xié)調(diào)，運行效率不高;層次式體系結(jié)構(gòu)的RTI采用分層結(jié)構(gòu)，具有前述兩種體系架構(gòu)的優(yōu)點，根據(jù)各節(jié)點請求的不同，分別采用集中處理或節(jié)點間直接通訊的方式進行報文投遞，有效地在效率和可靠性之間進行了平衡，也利于布置規(guī)模更大的仿真系統(tǒng)。

由于節(jié)點間通過網(wǎng)絡(luò)進行通信，節(jié)點所在網(wǎng)絡(luò)類型可能各不相同。報文在傳遞過程中需要對其進行轉(zhuǎn)換和處理，不同的報文處理和投遞方式是影響性能的另一重要因素。在基于RTI的分布式仿真系統(tǒng)中，節(jié)點間傳遞的消息有數(shù)據(jù)類消息和控制類消息兩類。控制類消息包含的是節(jié)點間關(guān)鍵的控制消息，需要采用可靠的點對點IP單播通訊方式;對于數(shù)據(jù)類消息，有關(guān)鍵數(shù)據(jù)和廣播數(shù)據(jù)之分，可分別對其采用單播或組播方式。由于層次式模型的特點，LRC(本地RTC組件)之間及LRC與CRC(核心RTI組件)之間根據(jù)不同的需求，可以采用通過CRC轉(zhuǎn)發(fā)消息方式或是任兩個LRC間都直接建立連接的方式。直接連接的方式可以獲得良好的實時性能，但在節(jié)點數(shù)目較多的情況下，占用資源十分巨大。

1.3 吞吐量測試分析

吞吐量是能從總體反映系統(tǒng)對數(shù)據(jù)處理能力的指標(biāo)。在規(guī)模較大的分布式仿真系統(tǒng)中，節(jié)點成員較多，在系統(tǒng)中投遞的報文數(shù)據(jù)量十分可觀。系統(tǒng)在單位時間內(nèi)能夠處理的報文數(shù)量(吞吐量)是反映系統(tǒng)性能的重要指標(biāo)。在報文發(fā)送能力和報文接收能力兩者之中，使用每秒能處理的最小平均速率來表示系統(tǒng)的屬性吞吐量。

在分布式仿真應(yīng)用中，位于不同物理位置的節(jié)點通過網(wǎng)絡(luò)進行信息交換。為了提高系統(tǒng)整體運行效率，減少對網(wǎng)絡(luò)帶寬的消耗，在RTI的各種實現(xiàn)中采用了不同的數(shù)據(jù)分發(fā)機制。在數(shù)據(jù)分發(fā)機制中，各發(fā)送數(shù)據(jù)的聯(lián)邦成員會在發(fā)送的報文中包含數(shù)據(jù)適用的范圍，接收報文的聯(lián)邦成員在加入聯(lián)邦時，會向系統(tǒng)聲明所需接收的數(shù)據(jù)類型，當(dāng)兩者匹配時，RTI才會通過網(wǎng)絡(luò)在相應(yīng)的范圍內(nèi)投遞數(shù)據(jù)，從而減少了對帶寬資源的消耗。

2 BH RTI性能測試方案設(shè)計

2.1 概述

本文設(shè)計的分布式仿真性能測試系統(tǒng)運行在100M以太網(wǎng)環(huán)境中，采用TCP/IP協(xié)議進行通信，各節(jié)點計算機使用WINDOWS XP操作系統(tǒng)。節(jié)點間的網(wǎng)絡(luò)通信基于BH RTI分布式仿真運行平臺。測試方案的目的是考核BH RTI分布式仿真平臺的運行效率，測試系統(tǒng)使用VC++2005在BH RTI提供的接口基礎(chǔ)之上進行開發(fā)。性能測試網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)圖如圖1所示。

BH RTI性能測試網(wǎng)絡(luò)拓?fù)鋱D說明:

(1)中間的服務(wù)器上運行的是BH RTI Central Server，其上運行BH RTI管理服務(wù)，減少了大規(guī)模分布式仿真中進行全局一致性操作所占用的大量網(wǎng)絡(luò)帶寬，有利于進一步擴大仿真應(yīng)用規(guī)模。

(2)各節(jié)點運行BH RTI 2.3軟件，同時還運行基于BH RTI 2.3開發(fā)的測試軟件。測試軟件可以選擇數(shù)據(jù)通信方式(一對一或一對多)、數(shù)據(jù)量大小和數(shù)據(jù)發(fā)送頻率。測試系統(tǒng)中每節(jié)點發(fā)送的數(shù)據(jù)量從32Byte～4KByte之間可調(diào)，發(fā)送頻率從10ms～10s之間可調(diào)。當(dāng)節(jié)點間采用一對多方式進行通信時，采用組播方式，以節(jié)省網(wǎng)絡(luò)帶寬。

2.2 BH RTI 2.3性能測試指標(biāo)及測試結(jié)果

本文對BH RTI 2.3在時間推進、屬性更新延遲和吞吐量三個方面的性能指標(biāo)進行了測試。

(1)時間推進請求響應(yīng)測試:主要測試推進一個事件所消耗的時間。編寫測試程序時需要對屬性的更新次數(shù)、更新的屬性數(shù)據(jù)量、采用的數(shù)據(jù)投遞機制(Reliable or Best Effort)、發(fā)送失敗時重新請求的次數(shù)進行考慮?？紤]使用兩個聯(lián)邦成員參與測試，運行測試程序，讓參與測試的成員盡最大可能發(fā)出時間推進請求，運行一段時間后，計算在單位時間內(nèi)平均推進的次數(shù)。

圖1 BH RTI性能測試網(wǎng)絡(luò)拓?fù)鋱D

在如圖1所示的網(wǎng)絡(luò)環(huán)境中，測試的結(jié)果如下:

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次循環(huán)，每次循環(huán)以每秒所有盟員推進的次數(shù)為單位。從結(jié)果來看，BH RTI 2.3在具有10臺主機節(jié)點的環(huán)境中，每秒推進的次數(shù)在1000次左右。

(2)更新延遲測試:參與測試的兩個聯(lián)邦成員在程序中采用“Ping－Pong”的發(fā)送方式進行屬性更新。編寫測試程序時需要對對屬性的更新次數(shù)、更新的屬性數(shù)據(jù)量、采用的數(shù)據(jù)投遞機制(Reliable or Best Effort)、發(fā)送失敗時重新請求的次數(shù)進行考慮。設(shè)兩個聯(lián)邦成員分別為甲和乙。成員甲首先發(fā)出更新請求，RTI將成員甲的屬性更新反射給成員乙，成員乙收到請求后立刻發(fā)出一個新的屬性更新請求，RTI將成員乙的屬性更新反射給成員甲，成員甲收到后同樣再發(fā)出一個新的屬性更新請求，測試程序運動一段時間后，計算每次屬性更新的所消耗的時間，即是屬性更新延遲時間。

在如圖1所示的網(wǎng)絡(luò)環(huán)境中，測試的結(jié)果如下:

＞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

屬性的更新延遲測試時發(fā)送的數(shù)據(jù)包大小分為32字節(jié)、256字節(jié)，分別循環(huán)10次。從測試結(jié)果看，延遲時間都在毫秒級。

(3)吞吐量測試:系統(tǒng)吞吐量能從總體反映系統(tǒng)對數(shù)據(jù)的處理能力。編寫測試程序時需要對對屬性的更新次數(shù)、更新的屬性數(shù)據(jù)量、采用的數(shù)據(jù)投遞機制(Reliable or Best Effort)、發(fā)送失敗時重新請求的次數(shù)進行考慮。對于發(fā)送屬性的聯(lián)邦成員，更新吞吐量由單位時間內(nèi)發(fā)出UAV(Update Attribute Value)調(diào)用的次數(shù)決定。對于接收屬性更新的聯(lián)邦成員，反射屬性吞吐量由單位時間接收到RAV(Reflect Attribute Values)調(diào)用的次數(shù)而決定，兩者之中的最小值即為系統(tǒng)的吞吐量。

在設(shè)計測試程序時，需要注意的是，在反射屬性回調(diào)函數(shù)中的代碼應(yīng)盡量精減。在測試結(jié)果中需要記錄查找函數(shù)的時間復(fù)雜性和查找的對象數(shù)目。

測試的結(jié)果反映平均更新屬性值速率、平均反射屬性值速率和平均發(fā)送交互速率、平均接受交互速率［4］。在如圖1所示的網(wǎng)絡(luò)環(huán)境中，測試的結(jié)果如下:

32個字節(jié)時每秒更新屬性值次數(shù)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與之對應(yīng)的反射屬性吞吐量: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個字節(jié)時每秒更新屬性值次數(shù)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)算法，根據(jù)時間控制報文可靠性定理引入IP組播來處理控制報文的傳輸，提高了節(jié)點的處理效率，大大降低了報文的帶寬開銷，提高了系統(tǒng)的處理能力。

3 結(jié)論

本文通過對RTI理論的學(xué)習(xí)研究，設(shè)計了對BH RTI進行性能測試的方案，分別對BH RTI的時間同步，網(wǎng)絡(luò)延遲和吞吐量三方面編寫了性能測試程序。性能測試的結(jié)果表明BH RTI的時間同步性能很好，BH RTI 2.3在10臺主機連接時，每秒推進的次在1000次左右，網(wǎng)絡(luò)延遲比較低，屬性更新延遲都在毫秒級，滿足后續(xù)項目對性能指標(biāo)的要求。

［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］.軟件學(xué)報，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.