大約半小時後，距離最遠的四號車也報告說自己已經抵達了15公裡外的預定位置。
於是。
第一輪測試，正式開始。
首先，自然是對照組。
也就是按照傳統中繼模式，中繼站隻進行數據接收和轉發，而不對數據進行處理。
“各號車均已就位！”
無線電當中，傳來了現場測試指揮員付明義的聲音：
“一號車，開始發送數據！”
一時間，原本有些嘈雜的車廂當中，隻剩下空調和通信設備工作時的嗡嗡聲，以及包括常浩南在內，總共四個人的呼吸聲。
測試所用的數據內容是常浩南提前就設定好的，所以並不需要操作員現場輸入什麼。
隻要在操作界麵上選定內容，然後發送就行了。
不過，程序畢竟是用了不到一個月時間緊趕慢趕編出來的，也就不用考慮什麼UI交互之類的問題了。
不說彆人，哪怕常浩南自己，看著略顯簡陋的界麵都有點繃不住。
好在基本功能還是比較齊全的。
沒過多長時間，數據傳輸便逐漸接近了尾聲。
毫無疑問，哪怕不去看具體的結果，單憑感覺也能知道，結果並不樂觀――
網絡吞吐量並非一般理解當中的“平均網速”，測試方法也不是通過傳輸一定數據量的文件然後再除以最終用時，而是以一定速率發送一定數量的幀，並計算待測設備傳輸的幀。
如果二者相等，那麼就將發送速率提高並重新測試，直到接收幀少於發送幀的瞬間，其對應速率就是網絡吞吐量。
因此基本可以認為，測試時間越短，則結果越差。
另外不難看出，這種測試方式得到的結果雖然是一個字節/秒的帶寬單位，但卻絕不僅僅和傳輸帶寬有關。
更重要的其實是穩定性。
“1.4千字節/秒……”
幾乎在屏幕上出現數字的一瞬間，吳威就下意識念了出來。
哪怕在21世紀初，也是個慢得驚天地泣鬼神的結果。
正如他之前估計的那樣，在傳輸條件惡劣的地麵上，利用通信車進行多跳傳輸，不會有任何好下場。
實際上，二號車那邊測出的吞吐量高達170千字節/秒以上。
到了三號車，還剩下30千字節/秒左右……
而四號車就隻剩下1.4千字節/秒了。
足以見得增加中繼節點對於傳輸速度的毀滅性影響。
當然，如此誇張的結果確實是本地自然乾擾較大導致的特例。
但趨勢總歸是沒錯的。
“打開各號車的編碼和解碼功能，重新進行測試！”
常浩南記錄下實驗數據，然後對著無線電下令道。
對於他來說，對照組的結果越差，反而越貼近於成功。
不過，一切的前提是。
實驗組真能測出一個更好的數據出來。
……
隨著機櫃的散熱風扇重新嗚嗚轉起，第二次測試，也正式開始。
理論上，在啟動了編碼和解碼功能之後，網絡吞吐量將可以逼近香農極限。
雖然實際操作中還是會受到諸多影響，但無論如何，結果應該都會明細優於之前才對。
而測試過程，果然也不負眾望。
持續時間比第一次長了幾倍。
儘管結果好壞與時間長短隻是呈正相關而不是呈正比，但這至少是個不錯的兆頭。
一直到十幾分鐘之後，屏幕上才像剛才那樣跳出一個代表四號車吞吐量的數字。
“6.8千字節/秒！”
這個結果讓吳威眼前一亮。
要知道，這些數字本身並不代表他這輛通信車的真實水平。
但提升的幅度可是實打實的。
將近5倍！
他絲毫不懷疑，如果自家產品用上這種技術，那麼即便過上5年，乃至10年，性能都不會完全過時……
“常總，這……”
他一臉興奮地看向常浩南，準備表達一下祝賀。
但話說出口才發現，對方的臉色……似乎並不太好看。
“不對啊……”
常浩南眉頭微皺，目光緊盯著屏幕上的結果喃喃道。
略顯怪異的反應直接把吳威給整懵了：
“不對……哪裡不對？”
“……”
迎接他的，是一陣沉默。
好一會之後，常浩南才用不知是自言自語還是回答問題的語氣輕聲說道：
“我之前在有線網絡內測試，結果就沒下過15倍……怎麼這次的效果就直接減弱了三分之二呢？”
聽到這句話，吳威差點被自己的口水給嗆到――
好家夥，這意思是嫌五倍的提升還不夠大唄？