技術(shù)案例分享：高溫流量測試丟包問題
對某以太網(wǎng)設備進行長時間的溫度循環(huán)測試，利用 SmartBits(SmartBits 設備，是由Spirent 公司開發(fā)的，用于以太網(wǎng)數(shù)據(jù)流量測試的設備。）對設備連續(xù)地、全速率地發(fā)送以太網(wǎng)數(shù)據(jù)包，測試人員發(fā)現(xiàn)一個奇怪的現(xiàn)象，設備在白天的測試中，均無丟包現(xiàn)象，夜間設備繼續(xù)運行，但是第二天一早就會發(fā)現(xiàn)已發(fā)生丟包。
《討論》
該設備的用戶接口是百兆以太網(wǎng)接口，利用5類非屏蔽雙絞線與 SmartBits 連接，由于端口數(shù)目較多，線纜布線較雜，存在線纜被實驗室管理員挪動的可能，在挪動過程中，可能導致丟數(shù)據(jù)包。經(jīng)與管理員確認，這種可能被排除。
溫度循環(huán)測試是指，通過對溫箱溫度曲線的控制，以實現(xiàn)調(diào)整產(chǎn)品工作所處環(huán)境溫度的目的。在這個測試中，溫度曲線如圖 6.9所示。
圖6.9高低溫循環(huán)測試溫度曲線
循環(huán)測試一個周期共 26h (h:小時)，分為六個階段。第一階段是用4h 均地從25℃降溫到-5℃，第二階段是在-5℃保持 5h，第三階段用 4h 均地從-5℃升溫到 25℃，第段用4h 均勻地從25℃升溫到 55℃，第五階段是在55℃保持 5h，第六階段是用4h從55降溫到25℃。在這個過程中，產(chǎn)品不間斷地全速運行。測試人員每天清早 9 點鐘開始一個周期的測試，到下午 6 點下班前檢查丟包情況，沒有發(fā)現(xiàn)丟包，第二天清早9點檢查，發(fā)現(xiàn)已經(jīng)出現(xiàn)丟包現(xiàn)象。頭天清早 9點到下午 6 點，循環(huán)測試正好完成了頭兩個階段，從夜間到第二天早上9點，完成第三、四、五階段以及第六階段的一半，即丟包現(xiàn)象總是發(fā)生在后四個階段。而后四個階段有兩個特點:一是升溫，二是高溫。在高溫 55℃下，測量單板上與 PHY 相關(guān)的信號完整性和時序，沒有發(fā)現(xiàn)問題。
利用 SmartBits 對以太網(wǎng)產(chǎn)品進行流量測試，有兩個原因可能丟數(shù)據(jù)包:一個是產(chǎn)品本身存在缺陷;另一個是SmartBits的晶振快于以太網(wǎng)產(chǎn)品上PHY使用的晶振在高溫下進行大量測試后，可基本排除產(chǎn)品缺陷造成丟數(shù)據(jù)包的可能性以下主要討論晶振快慢對數(shù)據(jù)傳輸?shù)挠绊憽?br>
SmartBits 是用于以太網(wǎng)性能測試的設備，在本案例中，其作用是以線速的速度產(chǎn)生以太網(wǎng)數(shù)據(jù)包，并發(fā)送給以太網(wǎng)交換機，以太網(wǎng)交換機收到數(shù)據(jù)包后，在內(nèi)部轉(zhuǎn)發(fā)，最終又將所有數(shù)據(jù)包發(fā)回SmartBits。SmartBits 通過檢測發(fā)出的數(shù)據(jù)包數(shù)目和接收的數(shù)據(jù)包數(shù)目是否相等，來判斷是否發(fā)生了丟包。如圖6.10所示，假設SmartBits 上的IC1是負責收發(fā)數(shù)據(jù)包的芯片，數(shù)據(jù)包到達以大網(wǎng)設備，完成業(yè)務后，通過芯片 PHY1發(fā)送回 SmartBits。在這個過程中，SmartBits 上的ICl是基于晶振OSCI收發(fā)數(shù)據(jù)包，而以太網(wǎng)設備的PHY1是基于晶振OSC2收發(fā)數(shù)據(jù)包，由于雙方采用的不是同一顆晶振，在頻率上必然有一定的差別。假設 OSC1和OSC2都是25MHz(誤差士50ppm)的晶振(ppm指百萬分之一，此處，50ppm的誤差即為50Hz)，雖然標稱頻率和精度完全一樣，但實際振蕩頻率并不完全一樣。利用頻率計測量，在室溫下，OsC1的頻率是25.000050MHz，即25MHz(誤差+2ppm);OSC2的頻率是25.000100MHz，即 25MHz(誤差+4ppm)。OSC2略微快于 OSC1，即以太網(wǎng)設備上 PHYI的工作速率高于SmartBits上IC1的工作速率，因此在常溫下，以太網(wǎng)設備有能力將SmartBits發(fā)送來的數(shù)據(jù)包接收下來，并全部發(fā)回。
圖6.10 SmartBits 與以太網(wǎng)設備連接
白天的測試從不丟包，分析溫度循環(huán)曲線圖可知，白天的測試包括常溫和低溫兩種情況，在測試中，只有以太網(wǎng)設備被放置在溫箱中，而 SmartBits 一直工作在室溫環(huán)境，在低溫-5C下測量OSC2的頻率為25.000300MH，即25MHz(誤差+12ppm)，高于OSC1室溫下的頻率25MHz(誤差+2ppm)，因此，在低溫下，以太網(wǎng)設備同樣有能力將 SmartBits發(fā)送來的數(shù)據(jù)全部發(fā)回。
丟包現(xiàn)象都是發(fā)生在夜間，夜間的測試包括低溫、常溫、高溫三個階段，通過前面的測試已經(jīng)證實，低溫和常溫條件下，OSC2 的頻率都快于 OSC1，因此主要考慮高溫的情況。在55C，測量OSC2的頻率為 24.999825MHz，即25MHz(誤差-7ppm)，慢于OSC1，在這種情況下，以太網(wǎng)設備沒有足夠的能力將 SmartBits 發(fā)送來的數(shù)據(jù)包全部發(fā)回即對于以太網(wǎng)設備而言，接收到的數(shù)據(jù)包始終多于能發(fā)送出去的數(shù)據(jù)包，必然造成丟包。根據(jù)以上分析得到結(jié)論，夜間丟包的原因是高溫下 OSC2 的速率慢于 OSC1。為了檢驗這個結(jié)論，設計者將 SmartBits 發(fā)包速率從全速的 100%調(diào)整為97%，進行多個溫度循環(huán)測試，沒有發(fā)現(xiàn)丟包。由此證明丟包原因確系高溫下 OSC2 速度較慢。仔細查閱以太網(wǎng)設備上使用的晶振 OSC2的器件資料，發(fā)現(xiàn)晶振的輸出頻率隨著環(huán)境溫度的變化，也會有略微的變化，如圖 6.11 所示。
圖 6.11 晶振頻率一溫度變化曲線（-40~＋85°）
以 25C時晶振的頻率為基準，隨著溫度的降低，輸出頻率將先提高，再降低;隨著溫度的升高，輸出頻率將先降低，再升高。本例中，55C時的晶振輸出頻率相對常溫最多可能降低12ppm。
聲明：本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人，不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用，如有內(nèi)容侵權(quán)或者其他違規(guī)問題，請聯(lián)系本站處理。
舉報投訴
-
測試
+關(guān)注
關(guān)注
8文章
5269瀏覽量
126599 -
以太網(wǎng)
+關(guān)注
關(guān)注
40文章
5419瀏覽量
171596 -
晶振
+關(guān)注
關(guān)注
34文章
2859瀏覽量
68004 -
流量
+關(guān)注
關(guān)注
0文章
245瀏覽量
23891
發(fā)布評論請先 登錄
相關(guān)推薦
電池（包級）測試系統(tǒng)的技術(shù)原理和應用
電池（包級）測試系統(tǒng)是一種關(guān)鍵的測試工具，其技術(shù)原理和應用在多個領(lǐng)域中發(fā)揮著至關(guān)重要的作用。以下是對其技術(shù)原理和應用的具體介紹：一、
發(fā)表于 12-09 15:40
ubuntu ping 開發(fā)板存在嚴重的丟包情況，請問該怎么解決？
我現(xiàn)在在學習一個嵌入式Linux的項目，要實現(xiàn)主機，虛擬機，開發(fā)板三者的通信，我的一系列設置應該是沒問題的。但是在ubuntu上ping開發(fā)板時總是會出現(xiàn)很嚴重的丟包情況，有時甚至會有From
發(fā)表于 11-01 16:50
新加坡服務器的速度測試方法有哪些
測試新加坡服務器的速度和性能是確保服務器能夠滿足業(yè)務需求的關(guān)鍵步驟。以下是一些常用的方法和工具： Ping測試： Ping命令是一種基本的網(wǎng)絡診斷工具，用于測試與服務器的連接延遲和丟
工業(yè)交換機的零延遲和零丟包
在現(xiàn)代工業(yè)自動化和網(wǎng)絡通信的快速發(fā)展中，工業(yè)交換機作為連接各類設備的核心元素，其性能和穩(wěn)定性顯得尤為重要。零延遲和零丟包的概念不僅是技術(shù)上的追求，更是推動工業(yè)智能化進程的重要保障。傳統(tǒng)網(wǎng)絡在數(shù)
使用SPI連接MCU和ESP8266，頻繁出現(xiàn)丟包問題是什么原因呢？
您好；
我司使用SPI 連接MCU和ESP8266，同一個局域網(wǎng)內(nèi) 8臺左右機器同時上傳10MB 大小的文件到后臺，頻繁出現(xiàn)丟包問題；設備信號沒有問題，緊挨著路由器；另外換過不同型號路由器也沒有改善；大概會是什么原因呢
發(fā)表于 07-19 08:12
ESP8266_RTOS3.0串口0傳輸大量數(shù)據(jù)丟包的原因？
多個分段進入處理函數(shù)，后來使用example示例中的uart_echo，發(fā)現(xiàn)接收可以完整接收，但是當把數(shù)據(jù)原樣從串口0的tx輸出時，數(shù)據(jù)中間出現(xiàn)多次中斷丟包。
我發(fā)現(xiàn)用系統(tǒng)自帶的打印log的函數(shù)打印數(shù)據(jù)時，并不會出現(xiàn)丟
發(fā)表于 07-09 06:32
cy7c68013a-56ltxc搭載fpga傳輸數(shù)據(jù)丟包是哪里出了問題？
1.8m的一個圖像數(shù)據(jù)由fpga傳輸給usb芯片，再由cy7c68013-56ltxc芯片把數(shù)據(jù)傳輸給電腦，然后由軟件排列起來，發(fā)現(xiàn)數(shù)據(jù)出現(xiàn)了丟包，數(shù)據(jù)卻行，大家有什么看法？
發(fā)表于 07-03 08:26
串口通信的時候怎么避免丟包的情況？
1.如何避免在中斷里面執(zhí)行長時間的操作
2.串口通信的時候怎么避免丟包的情況
3.串口通信為什么不可以一次發(fā)送1000bit或者10000bit 也就是說一幀數(shù)據(jù)為 一位起始位 10000bit數(shù)據(jù)位 一位停止位
發(fā)表于 07-03 07:00
例程simple_sniffer接收wifi數(shù)據(jù)包時老是丟包，有什么改進辦法？
您好！
在用例程simple_sniffer接收wifi數(shù)據(jù)包時老是丟包，是否有什么改進辦法？
謝謝
發(fā)表于 06-26 07:41
ESP8266 STA+AP模式下丟包如何解決？
ESP8266 STA單模式下，發(fā)送成功率在99%以上，請問如果存在STA+AP模式下丟包bug的話（我在網(wǎng)上看到相關(guān)信息，說信道共用的問題）那么我的95%通訊成功率是否正常（基于這個bug的前提下），再問
發(fā)表于 06-26 06:25
CC2640R2L使用BLE的Notify功能，通過定時器每隔10ms向手機發(fā)送一包數(shù)據(jù)，會出現(xiàn)丟包的原因？
使用BLE的Notify功能，通過定時器每隔10ms向手機發(fā)送一包數(shù)據(jù)，每包數(shù)據(jù)20字節(jié)，發(fā)送大約4000包后出現(xiàn)丟包情況，每次丟1
發(fā)表于 05-30 07:43
奧迪威推出新一代高溫流量傳感器
隨著物聯(lián)網(wǎng)技術(shù)的迅猛發(fā)展，超聲波智能熱量表在“智慧城市”供熱系統(tǒng)中的應用越來越廣泛。為滿足市場對高精度、低耗損超聲波流量傳感器的需求，奧迪威從感知層出發(fā)，推出了新一代專供超聲波熱量表應用的流量傳感器——
網(wǎng)絡丟包率正常范圍及其影響因素
網(wǎng)絡丟包率正常范圍及其影響因素 網(wǎng)絡丟包率是評估網(wǎng)絡性能和穩(wěn)定性的重要指標之一。 一、網(wǎng)絡丟包率
工商網(wǎng)監(jiān)
評論