分布式I/O項目開發(fā)中實時以太網(wǎng)的應(yīng)用評估
嵌入式系統(tǒng)需要通過標準網(wǎng)絡(luò)接口與外界進行通訊，常規(guī)網(wǎng)絡(luò)包括以太網(wǎng)、TCP/IP和套接API。人們通常認為以太網(wǎng)具有非確定性，但是，本文通過測試和研究表明，當集成了100Mb(或1Gb)以太網(wǎng)端口的小型CPU成本經(jīng)濟、性能可行時，將有機會在分布式I/O中采用TCP/IP協(xié)議。 我以前所做的幾個嵌入式設(shè)計項目都需要這樣或那樣的網(wǎng)絡(luò)連接，這些項目不斷重復(fù)著同一主題，即嵌入式系統(tǒng)需要通過標準網(wǎng)絡(luò)接口與外界進行通訊。這些項目通常包括實時操作系統(tǒng)(RTOS)和常規(guī)網(wǎng)絡(luò)模式：以太網(wǎng)、TCP/IP和套接API。通常，這些系統(tǒng)中的以太網(wǎng)數(shù)據(jù)處理要么以非實時數(shù)據(jù)的形式轉(zhuǎn)交給后臺處理，要么數(shù)據(jù)本質(zhì)上是可循環(huán)的，只要數(shù)據(jù)在一段時間內(nèi)進行刷新(約15至30毫秒)，一切都可正常工作。換言之，我們并不奢望小于幾個毫秒的精度。 然而，我最近承擔了一項特殊的系統(tǒng)設(shè)計項目，該系統(tǒng)需要一個極低延遲時間的確定性網(wǎng)絡(luò)作為這一項目的核心。這促使我研究確定一般的網(wǎng)絡(luò)工具是否適合該任務(wù)。盡管研究期間可以參閱許多優(yōu)秀的網(wǎng)絡(luò)理論、標準化協(xié)議和結(jié)構(gòu)性原理，但性能規(guī)范始終難以捉摸，因為網(wǎng)絡(luò)系統(tǒng)存在許多不可預(yù)知的因素，如網(wǎng)絡(luò)硬件、網(wǎng)絡(luò)軟件、計算機硬件及操作系統(tǒng)等。通過這項研究，我加深了對TCP/IP和以太網(wǎng)性能特征的實際了解，而這些細節(jié)只能通過給定網(wǎng)絡(luò)的實際運用在實踐中獲得。
該項目的目標是通過嵌入式I/O處理器網(wǎng)絡(luò)來替代飛行模擬器中包含1,000多個I/O的高度集中式I/O系統(tǒng)，從而降低生產(chǎn)和設(shè)計成本。另外，由于降低了配線復(fù)雜性，生產(chǎn)效率預(yù)計也有所提高。新的分布式I/O系統(tǒng)包含許多遠程節(jié)點(位于其所服務(wù)的面板和儀器附近)，這些遠程節(jié)點相互連接，可在仿真處理器和各種飛行器及模擬器設(shè)備之間傳送數(shù)據(jù)。 最初，以太網(wǎng)被認為是******的網(wǎng)絡(luò)媒介選擇，它的確能夠滿足低廉硬件、低生產(chǎn)成本以及每個模擬器包含50至70個 I/O節(jié)點的要求。畢竟，集成有以太網(wǎng)功能的CPU面板隨處都可買到，因此可大大降低成本。圖1描述了最初設(shè)想的模擬計算機系統(tǒng)布局，它在分布式I/O中利用以太網(wǎng)作為網(wǎng)絡(luò)媒介。 然而，由于以太網(wǎng)是非確定性的，因此需要評估其它媒介。我們評估了各種網(wǎng)絡(luò)總線，包括反射式存儲器、現(xiàn)場總線(通常用于工廠自動化)、RS-485等，結(jié)果表明它們都不能經(jīng)濟有效地滿足要求。以太網(wǎng)看來是最合適的，唯一缺陷是非確定性數(shù)據(jù)傳輸(盡管已廣受注目)。此外，還必須研究以太網(wǎng)是否適用于要求較少延遲時間和確定性行為的系統(tǒng)。 以太網(wǎng)、TCP、UDP和IP 我曾多次聽到同仁們這樣老生常談：“以太網(wǎng)是非確定性的”。但是，以太網(wǎng)究竟不確定在哪兒？是因為它不受限制，還是僅僅定義適用公差的問題？為解決這些問題，讓我們先從以太網(wǎng)和TCP/IP的基本概念入手，做一下深入探討。 大多數(shù)應(yīng)用程序通過TCP/IP協(xié)議棧與以太網(wǎng)相聯(lián)，該協(xié)議棧采用分層的方式實現(xiàn)組成TCP/IP的各種子協(xié)議。在網(wǎng)絡(luò)界，TCP/IP是一套基于因特網(wǎng)協(xié)議(IP)的協(xié)議集的統(tǒng)稱，TCP是眾多協(xié)議中的一個。TCP/IP協(xié)議棧位于以太網(wǎng)驅(qū)動器之上，并與之緊密配合。換言之，TCP/IP通過排列輸出數(shù)據(jù)、緩沖輸入數(shù)據(jù)及提供網(wǎng)間路由機制，來協(xié)調(diào)應(yīng)用軟件和網(wǎng)絡(luò)驅(qū)動器之間的數(shù)據(jù)(信息包)流動。簡單的說，測試應(yīng)用軟件是通過套接API來訪問TCP/IP協(xié)議棧的。 TCP/IP協(xié)議提供了兩種可選的數(shù)據(jù)傳輸協(xié)議：TCP或UDP。兩者******的差別在于TCP可提供可靠的連接，確保接收方能收到所發(fā)送的每個信息包。而UDP是一種送畢即棄的協(xié)議，如果需要接收方確認，應(yīng)用軟件本身必須提供確認方式。人們或許傾向于更可靠的協(xié)議，但必須認識到可靠性是要付出代價的。 通過TCP協(xié)議發(fā)送的每一個信息包都要觸發(fā)接收堆棧發(fā)回一個確認信息包。對于少量數(shù)據(jù)而言，性能代價相當不合算。例如，如果要傳輸1字節(jié)的數(shù)據(jù)，須通過網(wǎng)絡(luò)傳輸一個64字節(jié)的信息包(以太網(wǎng)信息包的最小尺寸)，并相應(yīng)地發(fā)回一個64字節(jié)的確認信息包，這使得整個網(wǎng)絡(luò)的通信量增大一倍。在同樣的情況下，使用UDP協(xié)議只需發(fā)送初始信息包即可。因此，使用TCP協(xié)議將會給網(wǎng)絡(luò)添加不必要的開銷，而網(wǎng)絡(luò)并不需要更多的可靠性。 我們利用以太網(wǎng)硬件設(shè)備，即網(wǎng)絡(luò)接口(NI)，來連接網(wǎng)絡(luò)媒介。NI采用一種兩階段總線仲裁方案，即載波偵聽多路訪問與沖突檢測(CSMA/CD)，因此當設(shè)備檢測到總線未被占用時，便發(fā)送數(shù)據(jù)，這是總線仲裁協(xié)議的CSMA部分。該方案允許兩個或更多設(shè)備同時在總線上傳輸數(shù)據(jù)，這正是CD(沖突檢測)部分的由來。如果同時訪問總線的情景發(fā)生，設(shè)備便檢測到“沖突”，經(jīng)過一段隨機延遲時間，再重新向總線發(fā)送數(shù)據(jù)，直到發(fā)送成功為止。這就是以太網(wǎng)最基本的不確定性特征，然而，如果總線仲裁方案能在更高一級實現(xiàn)的話，還是有可能超越CSMA/CD方案的。 為克服以太網(wǎng)不可預(yù)測的仲裁方案，我們采用了一種軟件協(xié)議，規(guī)定網(wǎng)絡(luò)設(shè)備只有得到許可才能訪問總線。該協(xié)議并不限制CSMA/CD的使用，而只對控制以太網(wǎng)媒介訪問的高級(應(yīng)用)軟件起約束作用。為使該方案行之有效，必須建立以下規(guī)則：僅專有節(jié)點才能連接到網(wǎng)絡(luò)上；一個設(shè)備被指定為控制器，其余設(shè)備視為遠程節(jié)點；除非控制器發(fā)出請求，否則遠程節(jié)點不能訪問網(wǎng)絡(luò)總線；遠程節(jié)點有預(yù)先設(shè)定的時間來響應(yīng)控制器請求。 我們?yōu)?a >控制器節(jié)點設(shè)計了一個測試程序，控制器節(jié)點中的數(shù)據(jù)通過網(wǎng)絡(luò)傳送到遠程節(jié)點。該程序等待遠程節(jié)點的響應(yīng)數(shù)據(jù)，然后將其與原始傳送數(shù)據(jù)做比較，以檢測是否出錯。如果兩個數(shù)據(jù)不一致，或者過了預(yù)定時間遠程節(jié)點仍未做出響應(yīng)，測試程序便生成一個出錯信息。控制器軟件還可記錄信息包往返的最長、最短及平均時間。遠程節(jié)點軟件只等待控制器發(fā)來的輸入網(wǎng)絡(luò)數(shù)據(jù)，一旦收到數(shù)據(jù)，將對控制器做出回應(yīng)。觀測這些協(xié)作程序產(chǎn)生的往返數(shù)據(jù)處理時間可用于評價系統(tǒng)的性能。 投入測試 我們搭建的原型網(wǎng)絡(luò)由2個節(jié)點(控制器節(jié)點和遠程節(jié)點)組成，通過10BaseT以太網(wǎng)連接，以方便收集實驗網(wǎng)絡(luò)的吞吐量和測定時間。我們選用Phar Lap的TNT實時內(nèi)核作為所有節(jié)點的運行環(huán)境。除該內(nèi)核外，還用到了Phar Lap以太網(wǎng)設(shè)備驅(qū)動器和TCP/IP協(xié)議棧。我們?yōu)槊恳还?jié)點選用了Ampro 486級100MHz PC/104板。盡管我們的目標是在產(chǎn)品中使用帶有集成以太網(wǎng)10BaseT端口的CPU，但目前尚不可得。因此為了進行測試，我們使用了帶有SMC 91C94以太網(wǎng)接口芯片的Ampro PC/104網(wǎng)絡(luò)接口卡。將一個示波器連接到每一節(jié)點的并行端口也有利于時序分析；應(yīng)用軟件中某些數(shù)據(jù)位隨重要事件而設(shè)定和清除，它們被用作時序指示器。使用示波器對于該項目來說或許有點大材小用，但它提供了“清楚的校驗”，而且看來棒極了，尤其是對廣大的軟件工程人員而言。圖2示出了這一測試系統(tǒng)。 在控制器和遠程節(jié)點程序的邏輯序列中，控制器節(jié)點調(diào)用速率為60Hz，而遠程節(jié)點則不斷地循環(huán)。在控制器初始化階段，也會將信息包發(fā)往遠程節(jié)點。這迫使ARP協(xié)議接受初始化的影響，從而不干擾我們的實時測量。 對結(jié)果波形和軟件累加器的分析表明，2ms是******的往返時間，在此期間可向遠程節(jié)點發(fā)送64字節(jié)的有效載荷，并保證控制器收到響應(yīng)信息包；最壞情況下的往返時間為6ms。 單個節(jié)點完成往返處理必需的循環(huán)時間為16.7ms (相應(yīng)的頻率為60Hz)，最壞情況下的往返時間為6ms，該系統(tǒng)只能可靠地支持兩個遠程節(jié)點。顯然，該方案只能提供較小的吞吐量，對于單個飛行模擬器而言，需要25個或更多的這種獨立網(wǎng)絡(luò)。因此該系統(tǒng)需要巨大的性能突破，才能作為傳統(tǒng)堆架式I/O的一種可行替代方案。 保留TCP/IP 有兩個問題是顯而易見的。首先，對于10Mbps的信號速率，即便******情況下的2ms仍是很長的延遲時間；其次，所產(chǎn)生的抖動十分嚴重。我們將在稍后討論抖動問題。至于延遲時間，探討一下穿過導線的信息將對其時序特征的了解有所啟發(fā)。 測試中，我們向TCP/IP協(xié)議棧發(fā)送了64字節(jié)數(shù)據(jù)。如圖3所示，隨著協(xié)議報頭開銷的增加，信息包到達總線時，這64字節(jié)數(shù)據(jù)將變?yōu)辇嫶蟮?28字節(jié)。讓我們來計算一下126字節(jié)在10Mbps以太網(wǎng)上往返一次所需的最短時間。126字節(jié)等于1,008位，乘以100ns(10MHz的倒數(shù))得到100.8μs，再乘以2(因為數(shù)據(jù)被發(fā)送回來)，最終得到的往返時間為201.6μs。我們忽略了像傳播時滯這樣的次要因素，而實際上是達不到這一理論極限值的。但通過測量可知，最好情況下的結(jié)果是該極限值的10倍?？梢娺@并不太有效！ 早期帶有可變負載的內(nèi)核測試顯示，只要涉及定時和時序，內(nèi)核性能是一致不變的。因此，我們認為延遲時間和抖動很大程度上可能是由TCP/IP協(xié)議?；蛟O(shè)備驅(qū)動器引起的。于是，我決定重寫軟件程序，但不使用TCP/IP協(xié)議。由于Phar Lap網(wǎng)絡(luò)驅(qū)動器接口表現(xiàn)良好，而且使用現(xiàn)有的驅(qū)動器仍可保持部分硬件獨立性，因此，該計劃是要修改應(yīng)用程序代碼的網(wǎng)絡(luò)訪問模塊，以便直接與設(shè)備驅(qū)動器連接，而非套接庫。  這項修改絕非無足輕重，我們必須創(chuàng)建緩沖管理和信息包結(jié)構(gòu)代碼。這些改變使得應(yīng)用程序代碼的移植性下降，因為它變得僅適用于某一特定的操作系統(tǒng)。然而，如果性能的提高能帶來成本效益，那么這種折衷還是值得的。 軟件修改完成后，相同的程序(見表1和表2)將再次運行。最好情況下的往返時間為0.45ms，而最壞情況下為0.6ms。這一修改是分布式I/O項目開發(fā)中的重要步驟，它將最壞情況下的性能提高了一個數(shù)量級。性能的提高應(yīng)部分歸功于信息包開銷的降低，這固然緣于摒棄了UDP和IP報頭，但更大程度上還在于數(shù)據(jù)無需通過功能更多的協(xié)議棧。 在新的結(jié)構(gòu)中，每個網(wǎng)絡(luò)系統(tǒng)能在最高要求速率下，以最小有效載荷支持20個遠程I/O節(jié)點。 圖4是從連接到原型系統(tǒng)并行端口的示波器捕獲的屏幕圖像，以下是對其跡線的描述：
圖5在原型系統(tǒng)經(jīng)驗值的基礎(chǔ)上，顯示了平均信息包大小對往返時間的影響。值得注意的是，由于以太網(wǎng)規(guī)定了信息包的最小長度，往返時間絕不會低于500μs。 構(gòu)建系統(tǒng) 控制器節(jié)點將解析配置文件，并為每一遠程節(jié)點存儲配置信息。當遠程節(jié)點在線時，這些信息可通過網(wǎng)絡(luò)動態(tài)配置遠程節(jié)點。為確保系統(tǒng)的確定性，網(wǎng)絡(luò)中的遠程節(jié)點只有先收到控制器的傳輸請求，才能在以太網(wǎng)總線上傳輸。此時它將向控制器發(fā)送一個信息包，該信息包與來自控制器的信息包類型應(yīng)相互匹配。換言之，如果控制器發(fā)送了一個數(shù)據(jù)包，指定的遠程節(jié)點必須發(fā)回一個數(shù)據(jù)包。同樣地，如果控制器發(fā)送了一個配置信息包，則唯一適合的響應(yīng)也是配置響應(yīng)信息包。遠程節(jié)點必須在兩次接收控制器信息包期間完成所有的數(shù)據(jù)處理和I/O掃描。 為******限度地利用CPU，控制器總是在等待當前節(jié)點響應(yīng)數(shù)據(jù)包到達期間處理前一個節(jié)點收到的信息包，然后再處理下一個節(jié)點傳輸?shù)男畔?。例如，如?a >控制器剛給遠程節(jié)點3發(fā)送了一個信息包，控制器接著將處理先前從節(jié)點2接收到的數(shù)據(jù)(如果有的話)；然后著手構(gòu)建發(fā)往節(jié)點4(或 |
