強實時應(yīng)用環(huán)境下VxWorks, Linux, RTAI和Xenomai系統(tǒng)的性能比較.doc

課程：嵌入式系統(tǒng) 作業(yè)：文獻翻譯 電工理論與新技術(shù)_130501_徐浩澤_YS1310501037 如有需要可提供電子版強實時應(yīng)用環(huán)境下VxWorks, Linux, RTAI和Xenomai系統(tǒng)的性能比較A. Barbalace, A. Luchetta, G. Manduchi, M. Moro, A. Soppelsa, and C. Taliercio摘要：使用配置MPC7455 PowerPC處理器的VMEbus MVME5500 開發(fā)板對Wind River VxWorks, Linux, RTAI和 Xenomai四種不同操作系統(tǒng)進行性能測試。以一個時間實時應(yīng)用的框架為例對中斷延遲，重調(diào)度和程序間通信時間進行比較。對Gb以太網(wǎng)通信的性能測試也在目標板上進行。為達成此目的，我們將Linux IP stack 和 RTnet，Xenomai和 RTAI的一種開源強實時通信協(xié)議移植到所用的系統(tǒng)中。測試結(jié)果顯示被測的開源軟件適用于強實時應(yīng)用環(huán)境。關(guān)鍵詞：實時系統(tǒng)，Linux, RTAI, Xenomai, ADEOS, RTnet, VxWorks, PowerPC.1. 簡介自1998年以來，實時反饋控制系統(tǒng)已經(jīng)被廣泛應(yīng)用于RFX-mod 實驗。RFX-mod是一個用于研究磁約束熱核聚變的環(huán)形裝置，坐落于意大利的帕多瓦。目前在使用的有7個控制單元，每個單元都包含一個使用摩托羅拉MVME5500單板機和其他ADC/DAC轉(zhuǎn)換器以及其他數(shù)字接口板的模組箱?？刂茊卧M成控制網(wǎng)絡(luò)，數(shù)據(jù)在各單元間進行實時交換。一個提供了通用功能以及數(shù)據(jù)處理和通信功能的軟件框架已經(jīng)在VxWorks平臺上搭建起來。VxWorks被廣泛應(yīng)用于物理學(xué)研究的原因包括：提供了一個集成開發(fā)環(huán)境，簡化了開發(fā)過程。程序在被下載到目標系統(tǒng)之前可以在主系統(tǒng)中做開發(fā)和仿真。提供了一個強大的多任務(wù)化環(huán)境，任務(wù)有固定的優(yōu)先級，可以通過一組豐富的進程間通信（IPC）機制進行通信。VxWorks的軟件模式與UNIX非常相似，尤其是I/O和網(wǎng)絡(luò)，對于熟練使用UNIX的開發(fā)者來說，編程變得非常簡單。但是，近年來，Linux系統(tǒng)的蓬勃發(fā)展使得將其應(yīng)用于實時控制系統(tǒng)變得極富吸引力。但是對于數(shù)據(jù)采集，或者更廣泛的說，對于所有不需要嚴格的時間確定性的任務(wù)，Linux已經(jīng)被應(yīng)用于科學(xué)實驗當中。但是Linux的一些特性使其不能被直接應(yīng)用于實時應(yīng)用，例如：動態(tài)優(yōu)先級。使用隨時變動的優(yōu)先級是解決分時的一個好方法，但是可能會使一個緊急事件無法足夠快的拿到CPU權(quán)限。分頁?？赡軙腩~外的延遲除非將頁在內(nèi)存中鎖定。內(nèi)存管理單元的重新映射。用戶程序占用CPU時重新映射進入內(nèi)存管理單元（MMU）的頁面表會減緩上下文切換。粗粒度的同步。由于內(nèi)核為非先發(fā)式，有時系統(tǒng)無法響應(yīng)冗長的內(nèi)核操作時。最近的2.6版本Linux內(nèi)核為以上問題提供了解決方案。事實上將固定優(yōu)先級與過程子集想聯(lián)系是可能的，這一版本的內(nèi)核通過精確定義不可中斷的程序段和自旋鎖保護而不是禁止中斷已經(jīng)被定制為先發(fā)制人的了。此外Linux kernel 2.6提供了一個新的O調(diào)度的實現(xiàn)?？紤]到交互可以被禁止，而且，給定了級別范圍，優(yōu)先級可以被固定，我們可以將Linux暫時考慮成一個軟實時操作系統(tǒng)并因此可以被應(yīng)用于許多可以忍受偶爾的系統(tǒng)響應(yīng)延遲的場合。但是Linux 2.6 仍然不適用于聚變反應(yīng)反饋控制這種強實時場合，在這種情況下，事實上,不可預(yù)測的反應(yīng)時間可能惡化控制的質(zhì)量，或者更糟糕的是，導(dǎo)致不可恢復(fù)的不穩(wěn)定性。然而，在引用文獻4和5中，借助脈沖性質(zhì)的實驗，Linux已經(jīng)被成功的應(yīng)用到了強實時場合。在這種情況下，大多數(shù)的時間過程控制系統(tǒng)不需要運行在實時模式。只有在等離子放電這一在大多數(shù)現(xiàn)有聚變實驗中只持續(xù)數(shù)秒的過程中才需要實時控制。因此當需要進行實時操作時禁止中斷是可行的，這實現(xiàn)了一個循環(huán)周期12s的整體抖動。在禁用中斷時,尤其要注意：代碼和數(shù)據(jù)必須被鎖定到內(nèi)存中來防止頁面錯誤，軟件不能依賴系統(tǒng)服務(wù)控制I/O。因此除了輪詢輸入數(shù)據(jù)和寫輸出數(shù)據(jù)，控制代碼不能與外部環(huán)境通信，對于一個固定的迭代次數(shù)，使用預(yù)配置的地址窗口。這個解決方案盡管在特定的應(yīng)用程序成功，仍然有各種各樣的原因使其不能被認為是一個結(jié)論，最主要的是因為在下一代聚變裝置中，控制系統(tǒng)被期望用于控制長時間放電，或者準穩(wěn)態(tài)過程。2. Linux 系統(tǒng)的實時擴展我們主要希望能找到一種方法，給Linux增加一些定義新的實時任務(wù)的可能性，從而保證在它們已經(jīng)準備好運行時，能在一個確定的時間內(nèi)獲得控制。這個特性是由兩個開源Linux擴展: RTAI和Xenomai提供。RTAI和Xenomai大多數(shù)概念相同(他們源自同一個項目)，都代表而不是代替了Linux，一個結(jié)合Linux工作的額外的組件，處理的實時任務(wù)的調(diào)度,讓Linux提供所有剩余的功能。但是，為了與Linux配合，額外的組件和Linux共享底層硬件是必要的。通過使用ADEOS超微內(nèi)核作為硬件功能的代理，RTAI 和Xenomai都實現(xiàn)了這種共享。特別的，ADEOS通常掌控硬件中斷，并為其他組件傳播通知序列。所以，Linux和RTAI（或Xenomai）代表ADEOS域，并由超微內(nèi)核作為管線從邏輯上組織起來。聲明在流水線前端的組件將先接收到中斷通知，然后可以決定ADEOS是否讓它們沿著域管傳播。在RTAI（或Xenomai）位于管道前端因而優(yōu)先于Linux的情況下，可以忽略Linux的實際運行，確定響應(yīng)時間。如 圖 1 所示這個組織在Xenomai中已經(jīng)完全實現(xiàn)。圖 1 Xenomai分層圖 2 RTAI的分層如 圖 2 所示RTAI有稍微不同的組織形式，與Xenomai讓ADEOS掌控所有的中斷源不同的是，RTAI攔截它們，使用ADEOS將那些RTAI不感興趣的中斷通知送給Linux（也就是，中斷不影響實時時序）。這樣混合過程的目的是提高性能，因為在這種情況下，如果中斷是要喚醒一個實時任務(wù)，就避免了由ADEOS管理中斷的開銷。RTAI和Xenomai都有一個活躍的開發(fā)者社區(qū)，都可以作為一個VxWorks的開源替代。為了評估是否適合我們的目標，我們進行了一組測量比較了Linux，RTAI，Xenomai和VxWorks的性能。我們使用PowerPC架構(gòu)，使用摩托羅拉MVME5500單板機，這個選擇的原因是PowerPC構(gòu)架在執(zhí)行浮點運算時性能要優(yōu)于x86構(gòu)架。此外，在開發(fā)RFX-mod的實時控制系統(tǒng)時，我們得到一個非常有價值的經(jīng)驗：使用PowerPC系列處理器提供的向量構(gòu)架組件（(AltiVec）進行并行浮點運行。但是，RTAI還沒有往PowerPC構(gòu)架進行移植，ADEOS也有程序錯誤而無法在我們的平臺上應(yīng)用。因此，為了在MVME5500單板機上使用RTAI和Xenomai（兩者都在ADEOS分層）我們先開發(fā)了一個補丁集。3. MVME5500平臺上LINUX，ADEOS，RTAI和XENOMAI的移植為了將Linux, ADEOS, RTAI和 Xenomai移植到目標板上，我們開發(fā)了一些補丁。為了安裝Linux，Vanilla Linux Kernel v 2.6.14使用了一個從摩托羅拉公司獲得的補丁。但是我們必須開發(fā)一個附加的補丁修正一些VME數(shù)據(jù)存取中的錯誤。超微內(nèi)核ADEOS已經(jīng)被移植到PowerPC架構(gòu)，但是有一個程序錯誤使其不能被應(yīng)用于使用Galileo GT-64260系統(tǒng)控制器的所有平臺。我們在一個新的補丁中已經(jīng)修正了這個錯誤。安裝Xenomai時并未做任何改動，因為已經(jīng)有PowerPC使用的版本，而且不需要特定板支持。Xenomai已經(jīng)在AEDOS完全分層。RTAI沒有PowerPC可用的版本，所以需要進一步的開發(fā)。最后，RTnet不需要額外的開發(fā)。ADEOS和RTAI兩個系統(tǒng)開發(fā)的補丁已經(jīng)被集成在官方的配置中。在RFX-mod官網(wǎng)上可以得到MVME5500板的所有Linux補丁。由于目標板是無盤的，系統(tǒng)引導(dǎo)首先由廠商提供的引導(dǎo)裝載程序Motload完成。Motload使用普通文件傳送協(xié)議(TFTP)從服務(wù)器下載內(nèi)核。Linux使用網(wǎng)絡(luò)文件系統(tǒng)(NFS)進行文件輸入/輸出。4. 性能測定為了評估性能，我們重點關(guān)注兩個特性：中斷延遲和延期時間。我們使用一個測試程序，acqloop，通過VME總線從ADC獲得64個cannel產(chǎn)生一個輸出到DAC板，對應(yīng)于獲得的第一個信號。雖然很簡單,這個程序可以測試我們感興趣的特性，因為當一組新的數(shù)字化數(shù)據(jù)已經(jīng)準備好后ADC會產(chǎn)生一個中斷。通過用示波器測量一個輸入信號和系統(tǒng)的輸出間的延遲，我們可以對系統(tǒng)的總體性能進行非擾亂性的測量，測定中斷延遲和延遲時間的不同。整體延遲中的其他部分實際上是對VME I/O的訪問引起的，在所有被測系統(tǒng)中可以認為是相同的。最后，我們考慮網(wǎng)絡(luò)實時通信，因為大多數(shù)聚變裝置的控制系統(tǒng)都涉及實時通信。RTAI和Xenomai都依靠Linux IP堆棧實現(xiàn)網(wǎng)絡(luò)通信。因此我們首先擴展我們的測試程序acqloop，通過以太網(wǎng)連接和使用UDP協(xié)議在另一塊板上生成輸出信號，對VxWorks和Linux的IP堆棧性能進行了比較。我們對UDP協(xié)議感興趣是因為它正在被現(xiàn)有的控制系統(tǒng)RFX-mod用于實時通信。然后我們考慮用一個開源項目RTnet，實現(xiàn)實時網(wǎng)絡(luò)通信。RTnet實現(xiàn)了一種新的IP堆棧 (對于UDP)，非確定性的原因被精確的避免了。特別的，為了避免內(nèi)存動態(tài)分配，數(shù)據(jù)包的內(nèi)存分配由預(yù)分配所有需要提前的緩沖區(qū)實現(xiàn)。RTAI和Xenomai都可以使用RTnet。在第一輪測試中，我們關(guān)注被測系統(tǒng)中斷延遲時間的差別。該情況下，acqloop首先安裝一個中斷服務(wù)程序(ISR)，直接讀取ADC數(shù)據(jù)寄存器并寫入DAC（通過VME）。對于VxWorks (v 5.5.1) acqloop為一個C函數(shù)實現(xiàn)，然后由shell調(diào)用，所有代碼運行在本機的內(nèi)核模式。其他系統(tǒng)，這段代碼集成為Linux模塊，因為它必須在內(nèi)核模式執(zhí)行。整個測量延遲是由于完成以下工作所需的時間組成：1) ADC板用于AD轉(zhuǎn)換；2) 控制板上的VME芯片用于檢測VME中斷,并將其傳播到系統(tǒng)控制器；3) 操作系統(tǒng)(OS)來處理中斷和調(diào)用副ISR；4) ISR從VME讀ADC數(shù)據(jù)；5) ISR向DAC寫輸出值；6) DAC轉(zhuǎn)換器輸出相應(yīng)的電壓值以上各段時間，只有第三段依靠操作系統(tǒng)實現(xiàn)。因此，被測系統(tǒng)的不同的測量延遲突出表現(xiàn)中斷延遲的差異。測得的時間如 圖 3 所示圖 3無重調(diào)度的測量延遲和抖動整體性能數(shù)據(jù)是相似的，最快的(VxWorks) 和最慢的 (Xenomai)約有5%的差別。進一步分析表明RTAI和Xenomai的差異是因為在Xenomai中，中斷總是首先被調(diào)度進入超微內(nèi)核，這就Linux而言引入一個小的開銷。相反的，RTAI在管理中斷時旁路了ADEOS，只有在中斷要傳播到另一個域（Linux）時才依賴ADEOS。值得注意的是RTAI的性能和VxWorks非常接近，而且，抖動顯然更小。在第二輪測試中，我們改變了acqloop程序，輸出不直接由中斷服務(wù)程序，而是由ISR設(shè)定的另一個等待信號量的內(nèi)核任務(wù)寫。測試結(jié)果如 圖 4 所示，每個條形圖的第二個部分代表重調(diào)度時間。圖 4有重調(diào)度的測量延遲和抖動Linux的性能不管是延遲還是抖動都令人驚喜，但是該測試結(jié)果僅表示系統(tǒng)不加載的情況下，當工作量增加時會很快減少。相對地，其他系統(tǒng)的性能測試結(jié)果被證明受工作負載的影響非常小，除非在高中斷率的情況下。VxWorks的性能和RTAI又非常接近，特別地，RTAI對執(zhí)行本地實時任務(wù)一個非常高效的調(diào)度器。在最后一輪測試中我們考慮了網(wǎng)絡(luò)通信，在這種情況下，等待信號量的進程不直接向DAC寫輸出，而是向另一塊寫DAC的MVME5500板發(fā)送一個包含所有獲得樣本數(shù)據(jù)的UDP數(shù)據(jù)包，UDP數(shù)據(jù)包的大小大約256字節(jié)（為了防止丟包，一些額外的字節(jié)用于UDP數(shù)據(jù)包時間標記）。有網(wǎng)絡(luò)通信的測量延遲如 圖 5 所示：圖 5有實時網(wǎng)絡(luò)通信的測量延遲本次性能比較中，Linux使用本地IP堆棧，RTAI和Xenomai都使用RTnet，VxWorks使用本地IP堆棧。值得注意的是VxWorks的網(wǎng)絡(luò)通信性能是較差的，事實上在RFX-mod上使用VxWorks最新的版本的時候，我們已經(jīng)體驗過這個情況。RTnet顯示了良好的性能，抖動很小。我們再一次觀察到RTAI和Xenomai有細微的差別，可能是中斷執(zhí)行路徑不同引起的。在上述測試中，我們禁止了RTnet的所有以太網(wǎng)訪問控制規(guī)則。我們使能以太網(wǎng)時分多址(TDMA)訪問規(guī)則后重復(fù)RTnet的上述實驗。該規(guī)則由RTnet選擇性提供，旨在強制網(wǎng)絡(luò)訪問中的決定論，避免可能的沖突。使用循環(huán)時間100s，數(shù)據(jù)分組時間片40s 的TDMA，我們獲得了一個約150s整體的延遲和約50s的抖動。減少TDMA的周期時間是不可能的（因此減少延遲和抖動也是不可能的）因為這將導(dǎo)致不可接受的CPU負荷。5. 討論本篇文章的目的是為了評估Linux實時解決方案替代RFX-mod目前正在使用的VxWorks的可能性?；谛阅軠y定的結(jié)果，我們可以得到以下結(jié)論：l 當前Linux 2.6內(nèi)核的性能非常好，在小的專用系統(tǒng)是可以接受的。但RFX-mod的反饋控制系統(tǒng)并非如此，涉及的控制單元要處理高數(shù)據(jù)吞吐量的輸入/輸出和網(wǎng)絡(luò)通信。l RTAI和Xenomai都值得考慮。Xenomai的性能表現(xiàn)略次于RTAI，主要是因為它分層的方法在中斷管理中引入一些開銷。另一方面，Xenomai結(jié)構(gòu)化更優(yōu)，很多平臺可以使用。此外，Xenomai提供一組模擬層，這在大型系統(tǒng)的移植中會非常有用。l RTAI和Xenomai在軟件開發(fā)時用戶友好都不及VxWorks。因為實時任務(wù)要在內(nèi)核模式執(zhí)行以實現(xiàn)最佳性能，程序員不能使用通常在用戶空間可用的系統(tǒng)服務(wù)，調(diào)試變得非常困難。然而，對于Xenomai和RTAI，讓用戶進程成為實時卻是可能的。允許實時應(yīng)用用戶進程的開發(fā)簡化了實時系統(tǒng)程序開發(fā)也允許IPC Linux標準進程。實時用戶進程靠一個與Linux調(diào)度器協(xié)同工作的專門的調(diào)度程序進行管理，當用戶進程需要實時性時，竊取它們。與內(nèi)核進程不同，為用戶進程進行上下文轉(zhuǎn)換需要重新映射頁表，這是一個潛在的耗時的操作。因為這個原因我們計劃進一步測試量化MMU重新映射對上下文切換的影響。l 網(wǎng)絡(luò)性能是對RTAI和Xenomai最有利的支持。UDP已成功用于實時網(wǎng)絡(luò)通信。RTnet被證實是一種良好的解決方案，尤其是的與目標板的最新版VxWorks IP堆棧的不良性能給我們的用戶體驗相比的時候。RTnet只在不使能TDMA時可以達到最佳性能，這似乎最適合有大量接入點但是沒有嚴格時間要求的系統(tǒng)（訪問沖突的機率更高）。RFX-mod并不是運行在這樣的環(huán)境下，只有不到10個控制單元。因此我們可以說，RTAI和Xenomai都可以在RFX-mod，或者更廣泛的說，在聚變裝置的實時控制系統(tǒng)有效替代VxWorks。參考文獻1 A. Luchetta and G. Manduchi, “RFX數(shù)字反饋控制的總體構(gòu)架，實現(xiàn)和性能” IEEE Trans. Nucl. Sci., vol. 47, pp. 186191, 2000.2 M. Cavinato, G. Manduchi, A. Luchetta, and C. Taliercio, “核聚變實驗中一般目的的實時控制框架” Trans. Nucl. Sci., vol. 53, pp. 10021008, 2006.3 Wind River 主頁, 在線.可訪問: http: .4 J. A. Stillerman, M. Ferrara, T. W. Fredian, and S. M. Wolfe, “Alcator C-Mod 數(shù)字實時等離子體控制系統(tǒng)” Fus. Eng. Des., vol. 81, pp. 19051910, 2006.5 B. G. Penaflor, J. R. Ferron, M. L. Walker, D. A. Piglowski, and R. D. Johnson