8位機(jī)嵌入式TCP通信速度的研究
掃描二維碼
隨時(shí)隨地手機(jī)看文章
0 引 言
長(zhǎng)久以來(lái),串行RS 232和RS 485通信技術(shù)一直是自動(dòng)化儀器、儀表中常用的通信標(biāo)準(zhǔn)。但近年來(lái),隨著計(jì)算機(jī)技術(shù)、網(wǎng)絡(luò)技術(shù)、通信技術(shù)的發(fā)展及其在工業(yè)自動(dòng)化系統(tǒng)中的應(yīng)用,使得工業(yè)自動(dòng)化系統(tǒng)和儀器、儀表領(lǐng)域加速了向智能化、數(shù)字化和網(wǎng)絡(luò)化方向發(fā)展的進(jìn)程。出現(xiàn)了電力線通信技術(shù)、無(wú)線紅外和藍(lán)牙通信技術(shù)、基于USB接口的通信技術(shù)、現(xiàn)場(chǎng)總線技術(shù)以及嵌入式Internet接入技術(shù)等新技術(shù)。其中基于嵌入式Internet接入技術(shù)的網(wǎng)絡(luò)化儀器是近年提出的全新概念,它是儀器檢測(cè)技術(shù)與現(xiàn)代計(jì)算機(jī)技術(shù)、網(wǎng)絡(luò)通信技術(shù)、微電子技術(shù)深度融合的產(chǎn)物口。檢測(cè)儀器接入Internet,成為執(zhí)行測(cè)量和控制任務(wù)的儀器Web站點(diǎn),這種網(wǎng)絡(luò)化儀器可以像普通儀器那樣按設(shè)定程序?qū)ο嚓P(guān)物理量進(jìn)行自動(dòng)測(cè)控、存儲(chǔ)和顯示等,同時(shí)允許已授權(quán)的用戶通過(guò)Internet遠(yuǎn)程對(duì)儀器進(jìn)行操作、監(jiān)控、故障診斷等。在具體的應(yīng)用中,出現(xiàn)了不少問(wèn)題,其中之一就是傳輸率和系統(tǒng)利用率不高,本文正是在這種背景下產(chǎn)生的。
1 TCP通信硬件接口
典型的8位機(jī)采用TCP協(xié)議接入Internet的以太網(wǎng)網(wǎng)絡(luò)接口如圖1所示。RTL8019AS以其優(yōu)異的性價(jià)比,成為目前單片機(jī)以太網(wǎng)系統(tǒng)的首選以太網(wǎng)接口芯片。該芯片符合IEEE802.3 10Base2和10BaseT標(biāo)準(zhǔn),具有自動(dòng)奇偶檢測(cè)和糾錯(cuò)功能,支持全雙工工作模式。如圖1中,RTL8019AS工作于8位跳線模式,數(shù)據(jù)線SD0~SD7與8位單片機(jī)(51系列)的數(shù)據(jù)線(AD0~AD7)相連,地址線A0~A4與8位單片機(jī)的地址線(A0~A4)相連。讀寫(xiě)信號(hào)經(jīng)74S04產(chǎn)生。RTL8019AS的基地址(配合引腳34(AEN))為 0x8000H,對(duì)應(yīng)RTL8019AS內(nèi)部地址0x300H。RTL8019AS通過(guò)網(wǎng)絡(luò)變壓器HR901170A和RJ45接口與以太網(wǎng)相連接入internet,隔離網(wǎng)絡(luò)上的干擾信號(hào)。
2 單片機(jī)系統(tǒng)中TCP通信問(wèn)題分析
TCP協(xié)議是TCP/IP協(xié)議簇的核心,也是最復(fù)雜的協(xié)議。但由于其獨(dú)特的自動(dòng)檢錯(cuò)和重發(fā)機(jī)制,實(shí)現(xiàn)了數(shù)據(jù)的可靠通信,但也正是由于其復(fù)雜性,在8 位機(jī)上實(shí)現(xiàn)TCP協(xié)議通信耗時(shí)就比較多,傳輸速率低下。TCP協(xié)議的數(shù)據(jù)通信過(guò)程,以客戶機(jī)為例進(jìn)行分析。圖2是典型的采集系統(tǒng)TCP數(shù)據(jù)通信的時(shí)間序列圖。在建立連接后,由客戶機(jī)向服務(wù)器發(fā)送數(shù)據(jù)。假設(shè)此時(shí)客戶機(jī)的啟始序列號(hào)為100,每次固定發(fā)送100字的樣數(shù)據(jù)。服務(wù)器負(fù)責(zé)接受該數(shù)據(jù),但不下發(fā)任何送數(shù)據(jù),只確認(rèn)所接收的數(shù)據(jù),其啟始序列號(hào)為50。對(duì)于單片機(jī)系統(tǒng),由于其處理速度和內(nèi)存資源的局限,通常的處理流程如圖3。
由于服務(wù)器(一般為裝有windows系統(tǒng)的微機(jī)或工業(yè)計(jì)算機(jī))并不是收到數(shù)據(jù)就直接發(fā)送確認(rèn),而是繼續(xù)等待接受序列中的其他數(shù)據(jù)。這就會(huì)經(jīng)常觸發(fā)服務(wù)器的接受延時(shí)的確認(rèn)算法,這將導(dǎo)致剩下的數(shù)據(jù)不能在200 ms內(nèi)發(fā)送。對(duì)于高速交互的采樣系統(tǒng)而言,這將產(chǎn)生明顯的時(shí)延。Host Requirements RFC申明TCP必須實(shí)現(xiàn)Nagle算法,但必須為用戶提供一種方法來(lái)關(guān)閉該算法在某個(gè)連接上的執(zhí)行。該算法要求TCP連接上最多只能有一個(gè)未被確認(rèn)的未完成的小分組,在該分組的確認(rèn)到達(dá)之前不能發(fā)送其他的小分組。實(shí)際使用Sniffer監(jiān)聽(tīng)軟件也得到同樣的結(jié)果,在接收到下位機(jī)的數(shù)據(jù)包后,上位機(jī)延時(shí) 200 ms后,發(fā)送確認(rèn)包,其傳輸速度為10 packet/s,實(shí)際網(wǎng)絡(luò)利用率不足1%。由圖3可見(jiàn),只要提高服務(wù)器確認(rèn)發(fā)送的速度,就可以提高通信的速度。對(duì)于本系統(tǒng)采用33M的主頻(C051F 單片機(jī))發(fā)送一個(gè)分組(1 024 B)和接受一個(gè)確認(rèn)分組(60 B)總用時(shí)為3~3.5 ms,關(guān)閉Nagle算法后,使用Sniffer監(jiān)聽(tīng)分析數(shù)據(jù)包,系統(tǒng)上位機(jī)在收到數(shù)據(jù)包后,立即發(fā)送確認(rèn)包,期間只有0.3 ms左右的網(wǎng)絡(luò)延時(shí),系統(tǒng)速率提高到設(shè)定的20 ms發(fā)送一次采樣數(shù)據(jù),即100 packet/s,系統(tǒng)利用率提高為為原來(lái)的10倍。
然而對(duì)于有些應(yīng)用場(chǎng)合,每次采樣的數(shù)據(jù)量并不大(小于100 B),采用關(guān)閉Nagle 算法來(lái)提高傳輸率是不理想的,因?yàn)檫@樣增加了網(wǎng)絡(luò)上傳輸?shù)姆纸M的數(shù)量,同時(shí)增大了客戶機(jī)(下位機(jī))處理這些多出來(lái)的分組的時(shí)間消耗,降低了系統(tǒng)利用率,增大了傳輸出錯(cuò)率,大幅度的減少了持續(xù)傳輸時(shí)間。實(shí)驗(yàn)中,當(dāng)采用高頻單片機(jī)(100M主頻),將數(shù)據(jù)通信速率提高到1 000 packet/s,發(fā)現(xiàn)傳輸錯(cuò)誤的數(shù)據(jù)包達(dá)到5%,同時(shí)傳輸持續(xù)時(shí)間由原來(lái)的大于48 h不間斷,減少為不足2 h,系統(tǒng)利用率也只有不到2%,同時(shí)已無(wú)法繼續(xù)提高傳輸速度(由硬件條件限制)。為解決這個(gè)問(wèn)題,同過(guò)分析具體TCP通信的各環(huán)節(jié)對(duì)時(shí)間的消耗過(guò)程,尋求在已有的硬件基礎(chǔ)上,通過(guò)軟件來(lái)解決問(wèn)題。
首先是數(shù)據(jù)分組打包。這里的耗時(shí)與要打包的數(shù)據(jù)量和主頻有關(guān)。為了便于計(jì)算,以下都用最簡(jiǎn)單的MCS-8051單片機(jī)為例進(jìn)行分析。對(duì)于發(fā)送100 B的數(shù)據(jù),外界晶振為12M的51單片機(jī),其一個(gè)機(jī)器周期為1μs。典型的打包代碼(包括TCP包和IP包)的執(zhí)行總周期約為2 200個(gè)機(jī)器周期(具體大小與編寫(xiě)軟件所使用的語(yǔ)言和編譯器有關(guān)),用時(shí)為2.2 ms。
其次是數(shù)據(jù)備份。TCP協(xié)議需要超時(shí)重發(fā),因而備份已發(fā)出而未收到確認(rèn)的數(shù)據(jù)分組是必要的。這里的耗時(shí)與數(shù)據(jù)量和主頻以及數(shù)據(jù)本備份的存儲(chǔ)器類型有關(guān)。對(duì)于100 B數(shù)據(jù)和40 B的頭部(包括TCP包的20 B頭部和IP包的20 B頭部),總共140 B的數(shù)據(jù)備份,采用外部存儲(chǔ)器,典型代碼的執(zhí)行周期為1 130個(gè)機(jī)器周期,用時(shí)為1.13 ms。
再次是發(fā)送數(shù)據(jù)分組。這里的耗時(shí)也與數(shù)據(jù)量和主頻有關(guān)。典型發(fā)送分組代碼的執(zhí)行總周期為2 200個(gè)機(jī)器周期,耗時(shí)為2.2 ms。
最后確認(rèn)分組。這里要做的工作有:檢測(cè)接口芯片,判斷分組類型,拆分IP包,拆分TCP包,典型代碼的執(zhí)行周期為4 130個(gè)機(jī)器周期,用時(shí)4.13 ms。
總共用時(shí)9.66 ms,其中接受確認(rèn)分組耗時(shí)最多,占總用時(shí)的42.8%。
3 改進(jìn)后的TCP通信方案
由上面分析可以看出,對(duì)于小分組來(lái)說(shuō),接收確認(rèn)分組的過(guò)程比較復(fù)雜,因而耗時(shí)也最多。因而控制服務(wù)器確認(rèn)分組的發(fā)送數(shù)量,成為提高效率的關(guān)鍵。
研究發(fā)現(xiàn)通過(guò)調(diào)整Nagle算法的延時(shí)時(shí)間(每個(gè)接口的延遲ACK定時(shí)器可通過(guò)設(shè)定注冊(cè)表表項(xiàng)TCPDelAckTicks 的值 (HKLM \ SYSTEM \CurrentControlSet\Services\Tcpip\Parameters\Interface\)來(lái)調(diào)整,該注冊(cè)表表項(xiàng)在MicrosoftWindows NT 4.0 Service Pack 4中首次引進(jìn))和采樣單片機(jī)的發(fā)送流程來(lái)控制服務(wù)器發(fā)送確認(rèn)的數(shù)量。
如圖4所示,這里發(fā)送數(shù)據(jù)分組并沒(méi)有等待確認(rèn)分組這個(gè)過(guò)程。當(dāng)有確認(rèn)到達(dá)時(shí),所做的工作正常情況下和圖3所示的系統(tǒng)沒(méi)什么區(qū)別,只是在當(dāng)丟失了分組后的異常狀態(tài)出現(xiàn)后,才在更新連接狀態(tài)時(shí)處理了超時(shí)檢測(cè)和出錯(cuò)重發(fā)等事件。之后在數(shù)據(jù)打包后也沒(méi)有備份,這里是采用了大存儲(chǔ)器數(shù)據(jù)偏移技術(shù),也就是說(shuō)在一個(gè)分組的確認(rèn)未到達(dá)時(shí),其原始數(shù)據(jù)是不會(huì)被覆蓋的,新的分組打包在其后的內(nèi)存單元中,這樣就節(jié)省了數(shù)據(jù)備份所消耗的時(shí)間,不過(guò)無(wú)形中增大了對(duì)內(nèi)存的需求。但本應(yīng)用針對(duì)的是小分組情況,所以實(shí)際需求的內(nèi)存并不大。實(shí)際工作中,為了使系統(tǒng)穩(wěn)定工作,應(yīng)建立2個(gè)TCP連接,一個(gè)用于服務(wù)器(上位機(jī))發(fā)送控制命令和進(jìn)行參數(shù)設(shè)定使用,一個(gè)用于客戶機(jī)(下位機(jī))上傳采樣數(shù)據(jù)使用。雖然TCP可以雙向傳送數(shù)據(jù),可實(shí)際工作中,發(fā)現(xiàn)這樣在高速通信下出錯(cuò)率比雙連接單向數(shù)據(jù)通信要高出許多,主要是因?yàn)榭蛻魴C(jī)(下位機(jī))對(duì)TCP頭部的確認(rèn)號(hào)和序列號(hào)的調(diào)整容易出錯(cuò)所致。實(shí)際使用3~5個(gè)采樣分組發(fā)送一個(gè)確認(rèn)分組。因?yàn)檠訒r(shí)太短體現(xiàn)不了效率的提高,但延時(shí)太長(zhǎng),如果出錯(cuò),將產(chǎn)生大量重發(fā)分組的情況,影響網(wǎng)絡(luò)性能,同時(shí)也增大了對(duì)內(nèi)存的需求量。通過(guò)使用Snifferr軟件進(jìn)行監(jiān)聽(tīng)比較,在同樣的采樣速率下,在改進(jìn)前,發(fā)送包速率為500packet/s,接收確認(rèn)包速率為500 packte/s,出錯(cuò)率5%,持續(xù)傳輸時(shí)間小于2 h;改進(jìn)后,發(fā)送包速率為500 packet/s,接收確認(rèn)包速率為183 packet/s,出錯(cuò)率小于0.1%,持續(xù)時(shí)間大于48 h。同時(shí),同樣的硬件條件下,理論上可以進(jìn)一步提高采樣速率。
4 典型應(yīng)用
對(duì)于高速、低數(shù)據(jù)量的采集或測(cè)控系統(tǒng),如石油管道的查漏和修復(fù)系統(tǒng),要求高速采集對(duì)管壁的超聲波掃描信號(hào),通常結(jié)合溫度、壓力、深度和角度信號(hào)為一組采樣信號(hào),其總量不足20 B。這些系統(tǒng)要求高的采樣速率,但每次采集的數(shù)據(jù)并不多,這就產(chǎn)生了大量小的數(shù)據(jù)分組,這些小分組將迅速降低系統(tǒng)性能和網(wǎng)絡(luò)性能。采用本方案,可以較好地解決這些問(wèn)題。
5 結(jié) 論
本文通過(guò)對(duì)TCP協(xié)議具體低層實(shí)現(xiàn)過(guò)程中各個(gè)環(huán)節(jié)對(duì)時(shí)間消耗的分析,找出了提高系統(tǒng)效率,提高通信速度的方法。實(shí)踐證明這樣的設(shè)計(jì)提高了系統(tǒng)的效率,提高數(shù)據(jù)傳輸率,降低了網(wǎng)絡(luò)上傳送冗余分組的數(shù)量,明顯改善了系統(tǒng)性能。特別適用于高速、低數(shù)據(jù)量的采集或測(cè)控系統(tǒng)。