對某以太網(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ù)運行,但是第二天一早就會發(fā)現(xiàn)已發(fā)生丟包。
《討論》
該設(shè)備的用戶接口是百兆以太網(wǎng)接口,利用5類非屏蔽雙絞線與 SmartBits 連接,由于端口數(shù)目較多,線纜布線較雜,存在線纜被實驗室管理員挪動的可能,在挪動過程中,可能導(dǎo)致丟數(shù)據(jù)包。經(jīng)與管理員確認(rèn),這種可能被排除。
溫度循環(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)品進(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)稱頻率和精度完全一樣,但實際振蕩頻率并不完全一樣。利用頻率計測量,在室溫下,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)證實,低溫和常溫條件下,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。為了檢驗這個結(jié)論,設(shè)計者將 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)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。
舉報投訴
-
測試
+關(guān)注
關(guān)注
9文章
6201瀏覽量
131345 -
以太網(wǎng)
+關(guān)注
關(guān)注
41文章
5997瀏覽量
180800 -
晶振
+關(guān)注
關(guān)注
35文章
3560瀏覽量
73435 -
流量
+關(guān)注
關(guān)注
0文章
250瀏覽量
24607
發(fā)布評論請先 登錄
相關(guān)推薦
熱點推薦
虹科一體化車載測試實現(xiàn)多協(xié)議數(shù)據(jù)零丟包
在智能網(wǎng)聯(lián)汽車開發(fā)中,CAN FD與車載以太網(wǎng)多協(xié)議并發(fā)的測試場景日益普遍,但傳統(tǒng)分散式測試設(shè)備常因系統(tǒng)集成復(fù)雜、數(shù)據(jù)處理能力不足導(dǎo)致數(shù)據(jù)丟包、延遲波動,影響
詳解網(wǎng)絡(luò)丟包故障排查過程
干運維這么多年,見過各種各樣的故障,但有些問題真的是讓人抓狂。前段時間遇到的一個MTU問題,差點讓我懷疑人生。表面上看是簡單的丟包,實際上折騰了整整兩天才定位到根因。今天就把這個案例完整地記錄下來,順便把MTU相關(guān)的知識點系統(tǒng)地梳理一遍,希望能幫到遇到類似問題的兄弟們。
使用內(nèi)置晶振的話,串口波特率最大可以設(shè)置多少,不會丟包嗎?
之前我用ST的某芯片,采用內(nèi)置晶振,將波特率設(shè)置115200,100ms收發(fā)一次數(shù)據(jù)發(fā)現(xiàn)就有丟包的情況了,想知道,芯源的MCU效果如何?有大佬試過使用內(nèi)置晶振的話,串口波特率最大可以設(shè)置多少,不會丟
發(fā)表于 01-19 06:48
以太網(wǎng)設(shè)備高溫流量測試丟包問題案例(晶振篇)
測試人員發(fā)現(xiàn)一個奇怪的現(xiàn)象,設(shè)備在白天的測試中,均無丟包現(xiàn)象,夜間設(shè)備繼續(xù)運行,但是第二天一早就會發(fā)現(xiàn)已發(fā)生丟
電源噪聲導(dǎo)致的數(shù)據(jù)丟包,如何確認(rèn)是電容ESR升高引起的?
電源噪聲導(dǎo)致的數(shù)據(jù)丟包,如何確認(rèn)是電容ESR升高引起的?
發(fā)表于 11-15 09:34
GD32F470+LWIP TCP偶爾丟包怎么解決?
的重發(fā)機(jī)制。
因此認(rèn)為是校驗和之類的原因校驗失敗丟包。
開啟了交換機(jī)端口鏡像,監(jiān)聽tcp到交換機(jī)后的數(shù)據(jù)流量,發(fā)現(xiàn)兩次上位機(jī)發(fā)送給板子出問題的tcp數(shù)據(jù)包的校驗和都是0x0000。
發(fā)表于 09-29 06:43
RK3568自制底板狂丟包?教你5分鐘用Delayline一鍵復(fù)活網(wǎng)口
在使用飛凌嵌入式RK3568核心板搭配自制底板時,由于PCB走線與參考設(shè)計存在差異,常導(dǎo)致RGMII接口時序異常,進(jìn)而出現(xiàn)網(wǎng)口不通或頻繁丟包的情況。本文將為大家提供一套簡單高效的調(diào)試方案,通過三步操作即可解決此類問題。
如何測試協(xié)議分析儀的實時響應(yīng)效率?
50萬pps)和觸發(fā)成功率(如99.9%)。
工具:流量生成器、分析儀丟包統(tǒng)計功能。
多協(xié)議混合測試
目的:驗證分析儀在混合協(xié)議環(huán)境下的實時響應(yīng)效率。
方法:
同時生成多種協(xié)議數(shù)據(jù)
發(fā)表于 07-24 14:19
RDMA簡介7之可靠傳輸
。RoCE v2協(xié)議實現(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
MPLS和SR傳輸技術(shù)的區(qū)別
當(dāng)你在游戲里“五殺”時卡頓,當(dāng)你在視頻會議中突然掉線,這些抓狂瞬間的背后,大多是數(shù)據(jù)傳輸丟包或者延遲造成的。而如何保證不丟包、低延遲,MPLS(Multiprotocol Label
物聯(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、高性能計算(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
技術(shù)案例分享:高溫流量測試丟包問題
評論