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