MAK-RTI性能介紹

1、MAK高性能的RTI：設(shè)計的性能Ben Watrous Douglas D.Wood Len Granowetter高性能是我們的代名詞雖然對RTI進行評估和比較有很多標準，但其中最重要的就是性能。能否選擇一個吞吐量最大，延遲性、帶寬及CPU的使用率最小的RTI，對一個HLA仿真應(yīng)用來說意味著是否能夠成功。高性能并不是偶然發(fā)生的-只有哪些從開始階段就本著最高性能設(shè)計，并能夠可能滿足當今HLA聯(lián)邦需求的RTI，才可能做到。這就是為什么MAK RTI如此獨特：以性能為設(shè)計目標。在我們涉及MAK RTI的設(shè)計如何導致其具有無比的性能之前，我們將討論其4個主要性能指標。延遲許多分布式仿真的文獻表明在不

2、失去實時交互的情況下，30到100毫秒的延遲是可以接受的。即使一個運行在60HZ的三維圖形應(yīng)用，在16毫秒內(nèi)計算和繪制一楨圖像， 5到10毫秒的延遲可能也不會對一個特殊事件有影響。同時即使采用100M的通訊網(wǎng)絡(luò)，MAK RTI的典型延遲時間都小于250微妙（低于1/4毫秒）-這足夠滿足大部分對實時性敏感的仿真系統(tǒng)的需求。吞吐量吞吐量是一個衡量RTI從網(wǎng)絡(luò)讀寫數(shù)據(jù)快慢的標準。從很多方面考慮，RTI性能標準中吞吐量甚至比延遲性更為重要，因為此指標意味者其處理擁有大量對象的聯(lián)邦，并頻繁發(fā)送更新數(shù)據(jù)的能力。在許多實時平臺級仿真中， 100到150字節(jié)數(shù)據(jù)的更新和交互是相當?shù)湫偷摹τ诖艘?guī)模的數(shù)據(jù)包，M

3、ak RTI基于100M以太網(wǎng)實現(xiàn)了每秒超過12000個數(shù)據(jù)包，相當于每秒的數(shù)據(jù)傳輸率超過16Mb。如采用捆綁方式，其性能超過以前的兩倍，即可以實現(xiàn)每秒26000次更新。對于更大的數(shù)據(jù)包，性能會有進一步的提高。事實上，對于有效數(shù)據(jù)為1000字節(jié)的數(shù)據(jù)包，可以達到每秒鐘超過7000個數(shù)據(jù)包的流量，即超過100M網(wǎng)絡(luò)最大理論吞吐量的70%。帶寬對于HLA常見的誤解就是RTI在帶寬使用上增加了大量的開銷。這對于某些RTI來說確實如此（特別是使用CORBA的那些），MAK RTI使用的是為帶寬效率設(shè)計的自定義傳輸格式。其標準頭僅為8字節(jié)，附加在每一個包的前面，所以最小的消息類型數(shù)據(jù)包只有16字節(jié)（如調(diào)

4、用publishInteractionClass()）。使用典型的RPR FOM Time/Space/Position屬性更新，其編碼的數(shù)據(jù)包大小大約是124字節(jié)，它比DIS Entity State PDU要小很多。CPU的占用 關(guān)于CPU的占用，我們以Mak RTI的代碼效率而自豪，在RTIspy GUI圖形界面上增加了顯示面板，顯示每一次RTI服務(wù)調(diào)用所花的時間。在一臺主頻為2.4G 的PC計算機上，調(diào)用一次subscribeObjectClassAttribute()所花的平均時間為50微秒。加入一個聯(lián)邦執(zhí)行花費60毫秒（大約1/15秒），其中大部分的時間是從硬盤讀取FED文件的時間

5、-而三方同rtiexec的握手時間小于10毫秒。關(guān)于基準的看法當然，和所有的基準測試一樣，這些都是在實驗室條件下進行的：僅僅是兩個聯(lián)邦，在網(wǎng)絡(luò)上沒有其他的通訊，聯(lián)邦成員除了收發(fā)數(shù)據(jù)包不做任何其他的工作，等等。但是，我們使用的是不帶任何特殊網(wǎng)絡(luò)硬件的貨架PC計算機，采用RTI默認的RTD設(shè)置，沒有針對測試進行特殊的設(shè)置和調(diào)試。因此這些數(shù)字可以確切的被用作自然狀態(tài)下評估的MAK RTI性能。當然，最理想的是很多聯(lián)邦在同樣的網(wǎng)絡(luò)拓撲結(jié)構(gòu)下，同樣的聯(lián)邦成員，采用不同的RTI進行實際的比較。第三方研究和比較多次證實了MAK RTI突出的效率和實用性。以性能為本的設(shè)計的真正意味者什么？早期的RTI執(zhí)行表現(xiàn)

6、了具有與高性能仿真不適應(yīng)的特征。這些問題給HLA留下了這樣一個印象，HLA本身就比較慢，這大大阻礙了HLA的采用。因此，當我們開始開發(fā)MAK RTI時，首要目標就是構(gòu)建一個能夠滿足實時應(yīng)用需求的RTI。直接用TCP和UDP 套接字，能夠確保數(shù)據(jù)傳輸通過盡可能少的軟件層數(shù)。特別為MAK RTI設(shè)計的“傳輸格式”，能夠確保數(shù)據(jù)包盡可能的緊湊。在MAK RTI的發(fā)展過程中，我們對Time Management, MOM, DDM等附加服務(wù)的實現(xiàn)同樣采用了以性能為本的原則。畢竟不僅僅只有飛行模擬器仿真應(yīng)用才關(guān)心實時性能。當我們實現(xiàn)這些服務(wù)的時候，我們嚴格遵循新功能不能影響最初子集性能的原則。設(shè)置RID

7、文件的參數(shù)可以允許禁止不需要的服務(wù)，假如不需要Time Management或者DDM服務(wù)，并且禁止了這些服務(wù)，那么數(shù)據(jù)傳輸格式將采用不包含這些信息的傳輸格式。總的來說，附加服務(wù)不會對延遲有較大影響，因為自原始RTI發(fā)布以來，通訊策略沒有大的變化。為此，我們花費了大量的精力，來保證聯(lián)邦可以對就不使用的服務(wù)不付出計算時間。例如，如果MOM被禁止，就沒有必要收集、發(fā)送MOM更新所需的信息。以性能為本同時考慮了針對需求可能差別非常大的仿真應(yīng)用的實現(xiàn)，因此可能會有不同的性能之間的折衷：l 如果仿真必須通過WAN（廣域網(wǎng)）或者窄帶網(wǎng)絡(luò)連接（例如人造衛(wèi)星或者無線電），那么最小化帶寬使用率成為最重要的目標。

8、l 對于Stealth這樣對處理器要求很高的仿真應(yīng)用，低CPU使用率則極為重要。l 語音傳輸取決于低延遲和其可預(yù)見性。l 對于包括大量實體的仿真應(yīng)用，高吞吐量和較少的系統(tǒng)調(diào)用帶寬開銷將是必要的。l 最后，對于由多個參與者和聯(lián)邦成員組成的大演練，系統(tǒng)可伸縮性可能變?yōu)闆Q定因素。在許多情況下，MAK RTI提供了幾個算法供用戶選擇，給用戶自主決定如何性能折衷的權(quán)力。盡管大多數(shù)的聯(lián)邦可以從中得到突出的性能，但Mak RTI的各種設(shè)置還是為用戶提供了高度的可配置性。例如，使用捆綁傳輸可以增加網(wǎng)絡(luò)吞吐量和最小化帶寬使用率，但要付出一些額外的CPU處理時間和延遲。此外，MAK RTI為用戶提供了通過RTI

9、Spy 插件中應(yīng)用程序接口來根據(jù)特定的聯(lián)邦定制RTI。HLA是一個規(guī)范，那么和實現(xiàn)有什么不同？HLA提供了一個定義明確的應(yīng)用程序接口，在某些情況中從應(yīng)用程序接口到特殊實現(xiàn)之間有明顯的映射對應(yīng)關(guān)系。但是，在HLA規(guī)范里有許多方面允許各種不同的設(shè)計選擇。事實上，這是HLA的目的所在-允許各廠商構(gòu)建不同性能折衷的實現(xiàn)來競爭，以便讓用戶選擇最適合自己聯(lián)邦需求的實現(xiàn)。在已存在的實現(xiàn)中最大的區(qū)別有以下幾個方面：l 第三方網(wǎng)絡(luò)層與自定義的傳輸格式l 可靠傳輸實現(xiàn)l 聯(lián)邦成員大使回調(diào)策略l 輕量模式的可用性l 使用廣域網(wǎng)的效率l DDM和Time Managements實現(xiàn)讓我們看幾個MAK RTI開發(fā)者制定

10、的特定實現(xiàn)的選擇，以及這些選擇對性能的影響?？煽總鬏?TCP Forwarder方式因為TCP協(xié)議同時僅僅支持一個接受者，當數(shù)據(jù)包需要通過TCP發(fā)送給多個接受者時，RTI開發(fā)者需要在兩個策略中做選擇。不是每一個聯(lián)邦成員的LRC對其他每一個聯(lián)邦成員做一個連接，就是必須采用其它轉(zhuǎn)發(fā)方式，即數(shù)據(jù)包被發(fā)送給轉(zhuǎn)發(fā)器，轉(zhuǎn)發(fā)器隨后給其它的所有的聯(lián)邦成員發(fā)送一個副本。下圖顯示了在一個擁有6個成員的聯(lián)邦中兩種設(shè)計方式的基本構(gòu)架。全部連接設(shè)計的最大優(yōu)點是延遲最小，因為一個數(shù)據(jù)包到達接受者僅需要一次網(wǎng)絡(luò)傳輸。但是，采用TCP轉(zhuǎn)發(fā)器方式帶來的第二次網(wǎng)絡(luò)傳輸?shù)母郊友舆t僅僅為一毫秒的幾分之一。即使采用TCP 轉(zhuǎn)發(fā)器，對于

11、可靠傳輸MAK RTI的延遲性也能夠控制在一毫秒之內(nèi)。我們將會看到，采用轉(zhuǎn)發(fā)器方式帶來的額外延遲和其帶來的其他優(yōu)點相比，微乎其微。此外，為了充分發(fā)揮UDP組播的優(yōu)勢，多數(shù)聯(lián)邦通過Best-Effort方式發(fā)送其大多數(shù)關(guān)鍵性數(shù)據(jù)，降低延遲。全部連接的其他優(yōu)勢是每次通訊傳輸需要最少的總傳輸量。TCP轉(zhuǎn)發(fā)器則需要一次從發(fā)送者到發(fā)送給轉(zhuǎn)發(fā)器的額外傳輸。在只有兩個聯(lián)邦成員的聯(lián)邦中，TCP 轉(zhuǎn)發(fā)器方式的確需要兩倍帶寬-每條消息需要兩次傳輸而不是一次。（這就是為什么TCP 轉(zhuǎn)發(fā)器方式在基準測試比較中表現(xiàn)較差，因為基準測試往往只運行兩個聯(lián)邦成員）。但是，隨著聯(lián)邦成員數(shù)量的增加，額外傳輸?shù)母郊友舆t會越來越少。例

12、如，在一個有20個聯(lián)邦成員的聯(lián)邦中，采用TCP 轉(zhuǎn)發(fā)器 的RTI需要做21次傳輸， 全連接方式的RTI需要20次傳輸。MAK RTI采用的TCP 轉(zhuǎn)發(fā)器方式相對于全連接方式有幾個主要的優(yōu)勢。最重要的就是將每個數(shù)據(jù)包發(fā)送給的多個聯(lián)邦成員的CPU開銷轉(zhuǎn)移到一臺單獨的計算機上，給具體的實時應(yīng)用提供了更多的計算能力。聯(lián)邦成員加入聯(lián)邦對其傳輸時間不產(chǎn)生影響，因為其將一個可靠消息發(fā)送給TCP 轉(zhuǎn)發(fā)器。相反，采用全連接方式時，隨著接收者數(shù)量的增加，聯(lián)邦成員發(fā)送消息所花的CPU時間線性增加，除非每一個聯(lián)邦成員都采用多處理器的計算機。當然，這將為聯(lián)邦成員計算具體的應(yīng)用留下較少的時間。這就是為什么采用TCP 轉(zhuǎn)發(fā)

13、器方式比全連接方式更適合大系統(tǒng)。隨著聯(lián)邦成員數(shù)量的增加，如果單一的TCP Forwarder不能滿足聯(lián)邦中的可靠通訊，可添加附加的TCP轉(zhuǎn)發(fā)器分擔傳輸負載。在全連接方式中不可能實現(xiàn)這樣的負載均衡。TCP 轉(zhuǎn)發(fā)器方式大大簡化了聯(lián)邦的網(wǎng)絡(luò)拓樸，同時會給RTI內(nèi)部帶來許多好處。它簡化了某些任務(wù)，如聯(lián)邦成員錯誤冗余計算，并且極大地提高了聯(lián)邦成員加入聯(lián)邦的速度，因為每個LRC調(diào)用僅僅需要建立一個單一的到TCP轉(zhuǎn)發(fā)器的連接。另外，也允許RTI方便地實現(xiàn)增加集中消息處理和數(shù)據(jù)過濾的功能。例如，轉(zhuǎn)發(fā)器可以基于數(shù)據(jù)訂購信息方便地過濾數(shù)據(jù)，來降低可靠通訊需要的帶寬。當“Smart Forwarding”激活時MA

14、K RTI能夠完全以上描述的各種功能。最后，TCP 更適合廣域網(wǎng)。雖然會用到多個轉(zhuǎn)發(fā)器，但可以保證在每一對局域網(wǎng)之間僅僅發(fā)送一次數(shù)據(jù)。接受端的轉(zhuǎn)發(fā)器再發(fā)給本地的每一個聯(lián)邦成員。在全連接方式下，每一對聯(lián)邦成員之間要有一次數(shù)據(jù)發(fā)送，這意味著一個同樣的消息可能會在兩個廣域網(wǎng)之間多次發(fā)送。哪種回調(diào)策略最好？主要的RTI實現(xiàn)提供了三種經(jīng)過聯(lián)邦成員大使回調(diào)將即將接收的數(shù)據(jù)傳給聯(lián)邦成員的基本策略：單線程tick，完全異步回調(diào)，異步I/O tick。單線程方式是三種策略中最簡單的。聯(lián)邦成員從其主線程中調(diào)用RTI Ambassador tick()函數(shù)。這時RTI從網(wǎng)絡(luò)上讀取所有未處理的信息，依次調(diào)用相應(yīng)的回調(diào)

15、函數(shù)。這個方法完全避免了多線程之間的通訊開銷。但是，作為這樣簡化的代價是聯(lián)邦成員必須接受在調(diào)用tick函數(shù)時調(diào)用網(wǎng)絡(luò)I/O的開銷。另外，調(diào)用tick的聯(lián)邦成員代碼可能需要調(diào)試以保證網(wǎng)絡(luò)層緩沖區(qū)不會溢出和丟失數(shù)據(jù)。在異步回調(diào)方法中，聯(lián)邦成員回調(diào)通過第二個線程觸發(fā)，因為數(shù)據(jù)信息已經(jīng)接受到，無需等待Tick調(diào)用。異步回調(diào)方法的最大優(yōu)點可能是將網(wǎng)絡(luò)I/O的開銷轉(zhuǎn)移到另外的線程上，因此即使網(wǎng)絡(luò)通訊負載很重，但聯(lián)邦成員代碼可以自由的執(zhí)行仿真運算。對于某些應(yīng)用來說，采用異步回調(diào)也提供了一個減少在回調(diào)機制中固有延遲的方法。特別是在那些應(yīng)用中，聯(lián)邦成員可以在其它線程中完全處理新數(shù)據(jù)，延遲可能被減少。但在大多數(shù)情

16、況下，預(yù)期延遲會減少只是一個幻想。這是事實：如果允許發(fā)生異步回調(diào)，其可能會較早被執(zhí)行。但是大多數(shù)的聯(lián)邦成員設(shè)計它們的回調(diào)時，僅僅對它們收到的數(shù)據(jù)進行排隊，或者將新屬性值存儲在對象狀態(tài)數(shù)據(jù)庫中供其他聯(lián)邦成員代碼以后訪問。如果是這種情況，用異步回調(diào)將沒有任何好處。比如疾駛在前面的汽車等待在紅燈前一樣，數(shù)據(jù)只能在聯(lián)邦成員隊列中或?qū)ο髮傩詳?shù)據(jù)庫內(nèi)等待，直到被聯(lián)邦成員最終實際使用。異步回調(diào)帶來的可能的好處是以在聯(lián)邦成員設(shè)計上增加復雜程度為代價的。聯(lián)邦成員開發(fā)者采用異步回調(diào)必須考慮使回調(diào)線程安全。因為回調(diào)從RTI接收數(shù)據(jù)時，主仿真線程對其沒有任何控制，所以必須采用鎖定機制，以保證主聯(lián)邦成員線程從其讀取數(shù)據(jù)

17、時，回調(diào)線程不會同時寫入數(shù)據(jù)到聯(lián)邦成員對象數(shù)據(jù)庫。異步I/O提供了在單線程tick和多線程異步調(diào)用之間的一個折衷方法。對于異步I/O來說，RTI創(chuàng)建了一個單獨控制網(wǎng)絡(luò)I/O的線程。消息從網(wǎng)絡(luò)上被讀取，保存在RTI的一個隊列里，當調(diào)用tick時，聯(lián)邦成員可直接使用。因為該線程對于RTI來說是內(nèi)部的，異步I/O可以在不用對聯(lián)邦代碼修改時被激活，所以聯(lián)邦成員沒有維持線程安全的負擔。同時，提供了許多異步回調(diào)的優(yōu)點：當消息到達時可以從有限的網(wǎng)絡(luò)緩存中立即讀取，這樣可以大大的減少在負載很大的聯(lián)邦上丟失的消息數(shù)目，并且將讀取網(wǎng)絡(luò)的開銷轉(zhuǎn)移出聯(lián)邦成員主線程。因為異步I/O在沒有增加任何額外復雜度的情況下提供了

18、異步回調(diào)具有的大多數(shù)好處，所以在MAK RTI中使用了這種方式。同時也有采用簡易單線程tick模式的能力，因為其更容易調(diào)試，需要最小的總運行開銷（無需從隊列中拷貝出消息和將消息拷貝到隊列里）。MAK RTI提高性能的獨有特性有哪些？只要符合HLA API的規(guī)定，RTI實現(xiàn)可任意添加針對公共聯(lián)邦問題的解決方案。例如，在單個局域網(wǎng)上，RTI典型采用組播或者廣播方式傳送數(shù)據(jù)包給許多接收者。但大部分的廣域網(wǎng)并不支持組播和廣播方式。像TCP一樣僅僅支持點到點的通訊。MAK RTI允許用戶通過UDP 轉(zhuǎn)發(fā)器最小化在廣域網(wǎng)上使用的Best-Effort通訊。像TCP 轉(zhuǎn)發(fā)器一樣，UDP 轉(zhuǎn)發(fā)器做為和遠程局域

19、網(wǎng)內(nèi)所有聯(lián)邦成員的唯一聯(lián)系點，與其將UDP消息通過廣域網(wǎng)發(fā)送給每個遠程聯(lián)邦成員，不如將其發(fā)送給UDP轉(zhuǎn)發(fā)器，轉(zhuǎn)發(fā)器然后在其區(qū)域網(wǎng)其采用組播重發(fā)消息。另外一個MAK RTI的關(guān)鍵特性是基于類的組播過濾解決方案。經(jīng)常被描述成“窮人的DDM”，基于類的組播過濾沒有任何開銷，無需改寫聯(lián)邦成員代碼，就可以提供很多DDM的優(yōu)點。聯(lián)邦設(shè)計者通過簡單修改RID配置，就能夠?qū)OM 類與組播地址映射起來。例如，所有的無線電通訊可以被限制在一個不同于用于實體狀態(tài)數(shù)據(jù)的特殊通道。無需任何聯(lián)邦成員或者RTI代碼處理，在網(wǎng)卡層就能濾掉不必要的數(shù)據(jù)，大大減少了RTI附加在每個聯(lián)邦成員上的CPU負載。當然最獨特的工具是MA

20、K RTI為最優(yōu)化性能提供的RTIspy plug-in API。該API允許聯(lián)邦設(shè)計者真正的打開RTI黑盒子，幾乎可定制RTI的所有功能來滿足聯(lián)邦的特定需求。MAK怎么樣幫助客戶達到他們希望的性能目標呢？MAK充分認識到：仿真性能需求會越來越高，為了使我們的客戶取得成功，MAK RTI必須不斷發(fā)展面對挑戰(zhàn)。根據(jù)用戶的需要MAK RTI會添加更多的新功能和新的優(yōu)化工具。新功能如數(shù)據(jù)包捆綁和“聰明的TCP 轉(zhuǎn)發(fā)器”已經(jīng)被加入到最新發(fā)布版本中，并且新的解決方案都在研發(fā)中。例如，利用RTIspy plug-in API開發(fā)的共享內(nèi)存機制已經(jīng)在MAK RTI中實現(xiàn)了，并且在不久的將來會集成到RTI內(nèi)，

21、以幫助用戶充分利用多處理器機器的優(yōu)點?！半[含的DDM”將允許RTI利用聯(lián)邦特定的特點智能地將數(shù)據(jù)只路由給那些需要該數(shù)據(jù)的聯(lián)邦成員。同時正在研發(fā)的包括其它的通訊技術(shù)，如RUDP（基于UDP的快速、可靠的協(xié)議），數(shù)據(jù)壓縮技術(shù)、區(qū)別服務(wù)質(zhì)量等等。附加基準信息下面是一張不同測試情況下的延遲性比較圖。在所有的情況中，所有測試都運行在操作系統(tǒng)為XP 2.4G P4處理器，經(jīng)HUB通過100M以太網(wǎng)連接的機器上。我們比較了原始網(wǎng)絡(luò)和RTI的性能，該性能通過運行基于套接字、僅僅在網(wǎng)絡(luò)上發(fā)送和接收數(shù)據(jù)的應(yīng)用程序獲得。從代表延遲的曲線可以看出， RTI緊緊的跟隨原始網(wǎng)絡(luò)通訊的延遲曲線，表明RTI本身沒有增加多少開

22、銷。開銷主要是由于RTI必須在發(fā)送數(shù)據(jù)前通過AttributeHandleValuePairSet序列化數(shù)據(jù)到網(wǎng)絡(luò)緩存，接受數(shù)據(jù)端從序列化數(shù)據(jù)中重構(gòu)AttributeHandleValuePairSet。對于可靠傳輸，相應(yīng)的比較是在兩個TCP網(wǎng)絡(luò)之間RTI的延遲性和原始網(wǎng)絡(luò)延遲性。雖然該指標包括了在TCP 轉(zhuǎn)發(fā)器內(nèi)數(shù)據(jù)包傳送花費的時間，但可以看出，甚至對于較大的數(shù)據(jù)包，從末端到末端、聯(lián)邦成員到聯(lián)邦成員所有的可靠傳輸?shù)难舆t性遠遠低于一毫秒。對于采用TCP 轉(zhuǎn)發(fā)器的RTI（比如MAK RTI）,關(guān)鍵在于TCP 轉(zhuǎn)發(fā)器必須運行在一臺專門的機器上。如果同一臺機器運行一個聯(lián)邦成員的同時作為TCP轉(zhuǎn)發(fā)器，那么聯(lián)邦成員處理會主導支配CPU，TCP 轉(zhuǎn)發(fā)器會缺少CPU處理時間，造成消息阻塞。根據(jù)我們的經(jīng)驗，如果針對MAK RTI在可靠傳輸上的第三方的基準測試顯