對某以太網(wǎng)設(shè)備進(jìn)行長時間的溫度循環(huán)測試,利用 SmartBits(SmartBits 設(shè)備,是由Spirent 公司開發(fā)的,用于以太網(wǎng)數(shù)據(jù)流量測試的設(shè)備。)對設(shè)備連續(xù)地、全速率地發(fā)送以太網(wǎng)數(shù)據(jù)包,測試人員發(fā)現(xiàn)一個奇怪的現(xiàn)象,設(shè)備在白天的測試中,均無丟包現(xiàn)象,夜間設(shè)備繼續(xù)運(yùn)行,但是第二天一早就會發(fā)現(xiàn)已發(fā)生丟包。
《討論》
該設(shè)備的用戶接口是百兆以太網(wǎng)接口,利用5類非屏蔽雙絞線與 SmartBits 連接,由于端口數(shù)目較多,線纜布線較雜,存在線纜被實(shí)驗(yàn)室管理員挪動的可能,在挪動過程中,可能導(dǎo)致丟數(shù)據(jù)包。經(jīng)與管理員確認(rèn),這種可能被排除。
溫度循環(huán)測試是指,通過對溫箱溫度曲線的控制,以實(shí)現(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)品不間斷地全速運(yùn)行。測試人員每天清早 9 點(diǎn)鐘開始一個周期的測試,到下午 6 點(diǎn)下班前檢查丟包情況,沒有發(fā)現(xiàn)丟包,第二天清早9點(diǎn)檢查,發(fā)現(xiàn)已經(jīng)出現(xiàn)丟包現(xiàn)象。頭天清早 9點(diǎn)到下午 6 點(diǎn),循環(huán)測試正好完成了頭兩個階段,從夜間到第二天早上9點(diǎn),完成第三、四、五階段以及第六階段的一半,即丟包現(xiàn)象總是發(fā)生在后四個階段。而后四個階段有兩個特點(diǎn):一是升溫,二是高溫。在高溫 55℃下,測量單板上與 PHY 相關(guān)的信號完整性和時序,沒有發(fā)現(xiàn)問題。
利用 SmartBits 對以太網(wǎng)產(chǎn)品進(jìn)行流量測試,有兩個原因可能丟數(shù)據(jù)包:一個是產(chǎn)品本身存在缺陷;另一個是SmartBits的晶振快于以太網(wǎng)產(chǎn)品上PHY使用的晶振在高溫下進(jìn)行大量測試后,可基本排除產(chǎn)品缺陷造成丟數(shù)據(jù)包的可能性以下主要討論晶振快慢對數(shù)據(jù)傳輸?shù)挠绊憽?br>
SmartBits 是用于以太網(wǎng)性能測試的設(shè)備,在本案例中,其作用是以線速的速度產(chǎn)生以太網(wǎng)數(shù)據(jù)包,并發(fā)送給以太網(wǎng)交換機(jī),以太網(wǎng)交換機(jī)收到數(shù)據(jù)包后,在內(nèi)部轉(zhuǎn)發(fā),最終又將所有數(shù)據(jù)包發(fā)回SmartBits。SmartBits 通過檢測發(fā)出的數(shù)據(jù)包數(shù)目和接收的數(shù)據(jù)包數(shù)目是否相等,來判斷是否發(fā)生了丟包。如圖6.10所示,假設(shè)SmartBits 上的IC1是負(fù)責(zé)收發(fā)數(shù)據(jù)包的芯片,數(shù)據(jù)包到達(dá)以大網(wǎng)設(shè)備,完成業(yè)務(wù)后,通過芯片 PHY1發(fā)送回 SmartBits。在這個過程中,SmartBits 上的ICl是基于晶振OSCI收發(fā)數(shù)據(jù)包,而以太網(wǎng)設(shè)備的PHY1是基于晶振OSC2收發(fā)數(shù)據(jù)包,由于雙方采用的不是同一顆晶振,在頻率上必然有一定的差別。假設(shè) OSC1和OSC2都是25MHz(誤差士50ppm)的晶振(ppm指百萬分之一,此處,50ppm的誤差即為50Hz),雖然標(biāo)稱頻率和精度完全一樣,但實(shí)際振蕩頻率并不完全一樣。利用頻率計(jì)測量,在室溫下,OsC1的頻率是25.000050MHz,即25MHz(誤差+2ppm);OSC2的頻率是25.000100MHz,即 25MHz(誤差+4ppm)。OSC2略微快于 OSC1,即以太網(wǎng)設(shè)備上 PHYI的工作速率高于SmartBits上IC1的工作速率,因此在常溫下,以太網(wǎng)設(shè)備有能力將SmartBits發(fā)送來的數(shù)據(jù)包接收下來,并全部發(fā)回。

圖6.10 SmartBits 與以太網(wǎng)設(shè)備連接
白天的測試從不丟包,分析溫度循環(huán)曲線圖可知,白天的測試包括常溫和低溫兩種情況,在測試中,只有以太網(wǎng)設(shè)備被放置在溫箱中,而 SmartBits 一直工作在室溫環(huán)境,在低溫-5C下測量OSC2的頻率為25.000300MH,即25MHz(誤差+12ppm),高于OSC1室溫下的頻率25MHz(誤差+2ppm),因此,在低溫下,以太網(wǎng)設(shè)備同樣有能力將 SmartBits發(fā)送來的數(shù)據(jù)全部發(fā)回。
丟包現(xiàn)象都是發(fā)生在夜間,夜間的測試包括低溫、常溫、高溫三個階段,通過前面的測試已經(jīng)證實(shí),低溫和常溫條件下,OSC2 的頻率都快于 OSC1,因此主要考慮高溫的情況。在55C,測量OSC2的頻率為 24.999825MHz,即25MHz(誤差-7ppm),慢于OSC1,在這種情況下,以太網(wǎng)設(shè)備沒有足夠的能力將 SmartBits 發(fā)送來的數(shù)據(jù)包全部發(fā)回即對于以太網(wǎng)設(shè)備而言,接收到的數(shù)據(jù)包始終多于能發(fā)送出去的數(shù)據(jù)包,必然造成丟包。根據(jù)以上分析得到結(jié)論,夜間丟包的原因是高溫下 OSC2 的速率慢于 OSC1。為了檢驗(yàn)這個結(jié)論,設(shè)計(jì)者將 SmartBits 發(fā)包速率從全速的 100%調(diào)整為97%,進(jìn)行多個溫度循環(huán)測試,沒有發(fā)現(xiàn)丟包。由此證明丟包原因確系高溫下 OSC2 速度較慢。仔細(xì)查閱以太網(wǎng)設(shè)備上使用的晶振 OSC2的器件資料,發(fā)現(xiàn)晶振的輸出頻率隨著環(huán)境溫度的變化,也會有略微的變化,如圖 6.11 所示。

圖 6.11 晶振頻率一溫度變化曲線(-40~+85°)
以 25C時晶振的頻率為基準(zhǔn),隨著溫度的降低,輸出頻率將先提高,再降低;隨著溫度的升高,輸出頻率將先降低,再升高。本例中,55C時的晶振輸出頻率相對常溫最多可能降低12ppm。
聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。
舉報(bào)投訴
-
測試
+關(guān)注
關(guān)注
8文章
5701瀏覽量
128834 -
以太網(wǎng)
+關(guān)注
關(guān)注
41文章
5633瀏覽量
175909 -
晶振
+關(guān)注
關(guān)注
35文章
3266瀏覽量
70109 -
流量
+關(guān)注
關(guān)注
0文章
248瀏覽量
24237
發(fā)布評論請先 登錄
相關(guān)推薦
熱點(diǎn)推薦
RDMA簡介7之可靠傳輸
。RoCE v2協(xié)議實(shí)現(xiàn)可靠傳輸?shù)?b class='flag-5'>技術(shù)手段共有三種,分別為:丟包重傳機(jī)制、流量控制及擁塞管理。接下來將就這三種技術(shù)手段進(jìn)行詳細(xì)分析。
(1)
發(fā)表于 06-13 10:01
使用NXP 88W8801芯片組進(jìn)行iPerf3測試期間TCP中的周期性丟包現(xiàn)象,怎么解決?
OS: Linux Buildroot
內(nèi)核版本: 4.9.0-1
Interface : USB
問題描述:
我在 TCP iPerf3 測試期間遇到周期性丟包。使用以下命令執(zhí)行測試
發(fā)表于 04-02 06:53
物聯(lián)網(wǎng)BLE技術(shù)助力防丟器方案PTR5618
隨著物聯(lián)網(wǎng)和低功耗藍(lán)牙(BLE)技術(shù)的快速發(fā)展,防丟器方案成為了解決日常生活中物品丟失問題的有效工具。
方案說明:
該防丟器方案基于BLE和物聯(lián)網(wǎng)技術(shù),由一個小巧的設(shè)備和手機(jī)APP應(yīng)用
發(fā)表于 03-18 09:50
信而泰PFC/ECN流量測試方案:打造智能無損網(wǎng)絡(luò)的關(guān)鍵利器
導(dǎo)語:AI算力爆發(fā)的背后,如何保障網(wǎng)絡(luò)“零丟包”? 在當(dāng)今數(shù)據(jù)中心網(wǎng)絡(luò)中,隨著AI、高性能計(jì)算(HPC)和分布式存儲等應(yīng)用的飛速發(fā)展,網(wǎng)絡(luò)的無損傳輸能力變得至關(guān)重要。PFC(基于優(yōu)先級的流量

STM32H743+USB3300傳輸采集的數(shù)據(jù)前幾次會丟包怎么解決?
的,丟包只會出現(xiàn)在USB斷開重連后,要多發(fā)幾次才會不丟包,有知道的佬嗎。使用官方的USB庫移植,和Cubemx配置也一樣有此問題。使用的是CDC虛擬串口的USB高速HS模式,在其他論壇
發(fā)表于 03-10 06:26
用CPLD來控制TLK1221有丟包情況,怎么解決?
用CPLD來控制TLK1221有丟包情況。所傳輸?shù)囊曨l信號在顯示器上面有條紋出現(xiàn)。請問是不是在8B/10B轉(zhuǎn)換時,沒寫好程序。AD和DA轉(zhuǎn)換我感覺沒有問題。
發(fā)表于 02-13 06:08
華納云如何解讀WinMTR的丟包率數(shù)據(jù)?
WinMTR顯示的丟包率數(shù)據(jù)是指在網(wǎng)絡(luò)路徑上,從你的計(jì)算機(jī)到目標(biāo)主機(jī)之間,數(shù)據(jù)包丟失的百分比。丟包率是網(wǎng)絡(luò)穩(wěn)定性的一個重要指標(biāo),它可以幫助識
電池(包級)測試系統(tǒng)的技術(shù)原理和應(yīng)用
電池(包級)測試系統(tǒng)是一種關(guān)鍵的測試工具,其技術(shù)原理和應(yīng)用在多個領(lǐng)域中發(fā)揮著至關(guān)重要的作用。以下是對其技術(shù)原理和應(yīng)用的具體介紹:一、
發(fā)表于 12-09 15:40
ubuntu ping 開發(fā)板存在嚴(yán)重的丟包情況,請問該怎么解決?
我現(xiàn)在在學(xué)習(xí)一個嵌入式Linux的項(xiàng)目,要實(shí)現(xiàn)主機(jī),虛擬機(jī),開發(fā)板三者的通信,我的一系列設(shè)置應(yīng)該是沒問題的。但是在ubuntu上ping開發(fā)板時總是會出現(xiàn)很嚴(yán)重的丟包情況,有時甚至?xí)蠪rom
發(fā)表于 11-01 16:50
新加坡服務(wù)器的速度測試方法有哪些
測試新加坡服務(wù)器的速度和性能是確保服務(wù)器能夠滿足業(yè)務(wù)需求的關(guān)鍵步驟。以下是一些常用的方法和工具: Ping測試: Ping命令是一種基本的網(wǎng)絡(luò)診斷工具,用于測試與服務(wù)器的連接延遲和丟
工業(yè)交換機(jī)的零延遲和零丟包
在現(xiàn)代工業(yè)自動化和網(wǎng)絡(luò)通信的快速發(fā)展中,工業(yè)交換機(jī)作為連接各類設(shè)備的核心元素,其性能和穩(wěn)定性顯得尤為重要。零延遲和零丟包的概念不僅是技術(shù)上的追求,更是推動工業(yè)智能化進(jìn)程的重要保障。傳統(tǒng)網(wǎng)絡(luò)在數(shù)
恒訊科技分析:如何測試海外靜態(tài)IP服務(wù)的穩(wěn)定性和速度?
Speedtest.net)或其他專業(yè)的代理測試工具。 2、連接到靜態(tài)IP:按照服務(wù)提供商的指示配置你的網(wǎng)絡(luò)設(shè)置,連接到分配給你的海外靜態(tài)IP。 3、進(jìn)行ping測試:使用ping命令測試IP地址的響應(yīng)時間和
使用Python進(jìn)行Ping測試
)請求包,然后等待目標(biāo)主機(jī)返回響應(yīng)包,從而測量網(wǎng)絡(luò)的延遲和丟包情況。隨著Python編程語言的廣泛應(yīng)用,越來越多的網(wǎng)絡(luò)工程師開始使用Python進(jìn)行自動化網(wǎng)絡(luò)

CYUSB3014在統(tǒng)信uos上為什么傳輸速度很慢并且丟包嚴(yán)重
包順序是亂的,usb3.0下更是一直丟數(shù)據(jù)或者長度不對。
目前usb2.0下單包大小8k,usb3.0下單包大小16k。采用異步通訊,也就是linux下開發(fā)包中給的cyusb_bulk
發(fā)表于 07-19 12:09
使用SPI連接MCU和ESP8266,頻繁出現(xiàn)丟包問題是什么原因呢?
您好;
我司使用SPI 連接MCU和ESP8266,同一個局域網(wǎng)內(nèi) 8臺左右機(jī)器同時上傳10MB 大小的文件到后臺,頻繁出現(xiàn)丟包問題;設(shè)備信號沒有問題,緊挨著路由器;另外換過不同型號路由器也沒有改善;大概會是什么原因呢
發(fā)表于 07-19 08:12
評論