USB轉千兆網卡這個品類過去十幾年基本是瑞昱RTL8153家族的地盤。輕薄本擴展網口、擴展塢的RJ45、工控機調試網口一插就到手Windows下免驅、Linux下r8152直接識別成熟得像街頭便利店。但這兩年越來越多的選型表上加了一行“國產化比例”于是CH398這顆國產USB轉千兆網卡控制芯片開始頻繁出現在替代清單里。這篇文章把我最近一次把CH398和RTL8153真刀真槍對比的過程完整記錄下來從原理圖、驅動適配、USB枚舉抓包一直寫到iperf3吞吐實測和踩坑清單適合硬件工程師、嵌入式開發以及做選型替代的采購同學參考。1. 為什么現在要把CH398拿出來跟RTL8153比1.1 國產化需求怎么落到USB轉網卡這顆料上先說個挺現實的事。以前做產品選型誰都不會專門去關心一顆USB轉網卡芯片的供貨渠道。RTL8153交期穩定、價格透明、文檔齊全整機廠直接照著參考設計畫板子就行。但最近兩三年供應鏈端的變化讓很多人意識到一顆不起眼的小芯片如果供貨卡住整條產線都得停下來等。于是“國產替代”這件事就從一個采購KPI變成了硬件工程師案頭的實際工作。而這種USB轉網卡芯片恰恰是替換的高頻對象用量不大、功能相對固定、國產廠商做得也不差替換成本比主控、電源管理這些核心芯片低很多。CH398能在這種背景下被提出來跟RTL8153比首先是市場有這個需求其次才是芯片本身參數能不能打。我這次拿到的樣片是CH398主要對比對象是RTL8153B。測試場景覆蓋了三個典型應用Windows筆記本擴展塢上的有線網口、Linux工控機上的冗余調試口、還有一顆放在樹莓派上做獨立千兆網卡用。基本能代表這塊芯片最常見的去處。1.2 CH398和RTL8153在定位上的真實差異先說一個很多人容易忽略的點同樣是“USB轉千兆網卡”USB接口跑在什么速率直接決定了這顆芯片能不能跑滿千兆。我手上這顆CH398樣片走的是USB 2.0 High-Speed通道也就是480Mbps的理論總線速率。RTL8153B則支持USB 3.0/3.2 Gen1理論帶寬5Gbps所以RTL8153B在USB 3.0口上能比較輕松地把千兆跑滿。而CH398如果走USB 2.0哪怕PHY和MAC都是千兆的實際吞吐也會被USB 2.0的總線帶寬卡住這屬于物理層面的限制驅動怎么調都突破不了。但話要說回來。很多實際場景并沒有跑滿千兆的需求。工控機調試、產線燒錄、嵌入式設備聯網需要的往往是“穩定能用的百兆以上帶寬”而不是持續千兆打滿。CH398在這種場景下規格上是夠用的而且外圍電路、功耗、成本都有優勢。選型的第一步是先想清楚你的產品到底需要多少帶寬而不是盯著“千兆”這兩個字就覺得必須跑滿。注意如果你看到一顆芯片標著“千兆網卡”先去看它USB接口是USB 2.0還是USB 3.0。USB 2.0的千兆網卡大概率實際吞吐在300Mbps上下這在很多場景夠用但別拿它去做NAS滿速傳輸。2. 硬件設計原理圖上那幾處必須盯住的地方2.1 從RTL8153換到CH398外圍要改什么如果你已經有成熟的RTL8153方案想把主控換成CH398建議的路徑不是直接替換而是把原理圖打開對照芯片手冊逐項過一遍。我這次改板子時主要動了這幾處第一是晶振。RTL8153B和CH398用的都是25MHz無源晶振這點可以直接沿用但晶振的負載電容值要按芯片手冊推薦值重新確認。我一開始偷懶照抄了原方案的18pF結果芯片插上后USB能枚舉但網口鏈路協商不穩定后來換回手冊推薦的12pF負載電容的晶振問題就消失了。晶振這地方看起來簡單實際上直接影響PHY的時鐘精度而PHY對時鐘抖動又很敏感。第二是EEPROM。RTL8153B方案里經常會配一顆93C46或者24C02之類的EEPROM用來存MAC地址和配置信息。CH398如果只在Windows下當普通網卡用不寫EEPROM也能工作芯片會用自己的默認配置上電。但如果你需要固定MAC地址、需要量產時每臺設備不同MACEEPROM這部分就得保留并確認芯片手冊里的I2C/SPI地址映射關系。第三是網絡變壓器和RJ45。這倆基本是通用的只是要注意CH398的PHY側中心抽頭接法。有些國產芯片的PHY內部已經有偏置網絡變壓器的中心抽頭可以直接接電源或者通過電容接地具體接法以手冊里的參考電路為準。我遇到過因為照抄其他方案導致link燈常亮但不能通信的情況最后就是中心抽頭供電沒接對。第四是電源紋波。USB轉網卡芯片在工作時電流變化很快特別是傳輸大流量數據時3.3V電源上的紋波會明顯變大。我實測CH398在滿載發送時如果LDO選得不好紋波能到50mV以上這時候丟包率會上升。建議在芯片電源引腳附近放一組10uF100nF的去耦電容不要省。2.2 Type-C口和USB差分線的那些坑現在很多擴展塢和網卡都直接做Type-C接口這里有兩個很容易踩的坑。一個是Type-C的CC引腳。如果你是按照傳統USB-A口的方案畫的板子直接接到Type-C座上大概率插上去沒反應。Type-C接口在作為device也就是被主機供電的設備時CC1和CC2引腳必須各放一顆5.1k下拉電阻到地主機才能識別到設備插入并輸出5V。這個點其實在很多USB相關的調試場合都會出現不只是網卡芯片我之前幫朋友查過一個Type-C轉串口板子不識別的問題最后也是CC引腳懸空導致的。另一個是D/D-差分走線。USB 2.0雖然速率不算極高但D/D-這兩根線的差分阻抗還是建議控制在90歐姆左右長度盡量短遠離時鐘線和電源走線。很多畫板的人覺得USB 2.0無所謂隨便走走就行實際做出來的板子在USB 3.0主機上可能沒問題但在老舊的USB 2.0 HUB上就經常出現“設備描述符請求失敗”。另外D/D-上的對地電容在芯片資料里如果沒有特別說明一般不需要額外加加了反而會影響信號邊沿導致眼圖閉合。如果你把網卡放在擴展塢內部還要注意USB線纜到Type-C座之間的路徑。擴展塢內部走線復雜D/D-如果穿過好幾層板、過了連接器信號質量會明顯下降。這種場景能選帶有信號完整性優化功能的芯片會省心很多但CH398本身更偏向簡單直接的方案所以布局上要自己多花點心思。3. 驅動適配與USB枚舉抓包3.1 Windows和Linux下的驅動適配路線硬件畫好、板子貼出來下一步就是接上電腦看能不能識別。這一步是決定替代方案能不能落地的關鍵也是CH398跟RTL8153差異最大的地方。RTL8153在Windows下有微軟WHQL認證驅動插上就自動裝好設備管理器里顯示“Realtek USB GbE Family Controller”。Linux內核里的r8152驅動也很成熟直接編譯進內核插上就生成ethX接口。CH398就沒有這么省心了Windows下第一次插入系統大概率會直接重枚舉成一個帶問號的未知設備需要手動安裝廠商提供的驅動包。我這次測試用的驅動是廠商隨樣片一起給到的安裝包里有Windows 7/8/10/11的x86和x64版本。安裝過程本身沒什么難度但有一點必須提醒安裝驅動之前不要先插設備先裝好驅動再插USB或者按安裝包要求的順序來否則容易留下一個驅動殘留導致后面怎么插都識別成“未知USB設備”。Linux下的適配路徑有兩種。如果CH398走的是標準的CDC-ECM或者RNDIS協議那么主流的發行版內核都能直接識別插上之后會出現usb0之類的接口。如果芯片走的是廠商私有協議那就需要廠商提供Linux驅動源碼自己編譯DKMS模塊。我拿到的這個版本就不是標準CDC類所以Linux下必須裝驅動模塊。裝完之后我建議把模塊加入開機加載列表否則每次重啟都要手動modprobe。這里給個判斷小技巧插上設備后先在Windows設備管理器里看它枚舉出來的設備類。如果顯示“網絡適配器”說明系統是用廠商INF驅動來匹配的如果顯示“USB Composite Device”或者“CDC”那說明走的是系統通用類驅動。Linux下可以用lsusb查看設備的bInterfaceClass如果是0x02Ethernet Networking或0x0ACDC Data大概率能被系統通用驅動認到。3.2 用USB抓包工具把“看不見的設備”揪出來驅動裝不上的時候最容易讓人摸不著頭腦。設備管理器里一直顯示“設備描述符請求失敗”而且代碼是43怎么看都不像芯片壞了可系統就是不認。這種問題建議直接用USB抓包工具看枚舉過程而不是盲目換驅動、換線、換電腦。Windows下我常用的是USBPcap配合Wireshark或者用USBlyzer這種商業工具。USBlyzer能直接看到設備枚舉時的每一步狀態包括Reset、SetAddress、Get Descriptor、Set Configuration這些請求。如果發現主機發送了GET_DESCRIPTOR請求但設備一直沒有回復那就說明芯片沒有正常上電或者D上拉電路有問題。USB協議這塊簡單說兩句。USB 2.0設備枚舉時最關鍵的一步是D或D-引腳上的上拉電阻。全速設備在D上拉1.5k到3.3V低速設備則在D-上拉主機檢測到這個電平變化才知道有設備插入然后才開始枚舉流程。如果芯片內部已經集成了上拉電阻那外部就不用再放如果外部自己加了一顆上拉導致上拉電平、阻值和內部電路并聯沖突設備反而可能識別不正常。我這次實測時就遇到過一個很隱蔽的問題板子在自研主板上識別正常但接到電腦前置USB口上就“設備描述符請求失敗”。用USB抓包一看發現是線材太長、D信號上升沿太差主機在高速握手階段失敗。后來把線纜從1.5米換成0.5米的屏蔽線問題直接消失。這種問題如果不抓包純靠換驅動能折騰你一下午。提醒USB抓包不是只能看枚舉故障。設備正常工作后還可以抓BULK IN/OUT端點的URB確認數據交互是否繁忙、有沒有頻繁的NAK重試。這對排查“網卡吞吐上不去”非常有用。4. 吞吐量實測CH398到底能跑多少4.1 iperf3測試環境與命令驅動裝好、接口up起來下一步就是跑吞吐量。這個環節不能省芯片標稱“千兆”實際能跑多少得用數據說話。我這次搭的測試環境是這樣被測設備是一臺裝了CH398網卡的Linux工控機另一臺是裝了RTL8153B USB網卡的Windows筆記本兩臺設備通過六類網線直連中間不經過交換機。測試軟件用iperf3工控機上跑服務端筆記本上跑客戶端。先交代一下測試命令方便你直接抄Windows筆記本作為發送端iperf3 -c 192.168.1.10 -t 30 -P 4 -i 1這條命令的意思是向服務端發起TCP流量測試持續30秒用4個并行連接每1秒打印一次結果。并行連接數很重要單線程TCP往往跑不滿帶寬多線程才能壓出真實水平。UDP測試用下面這條iperf3 -c 192.168.1.10 -t 30 -u -b 800M -i 1UDP測試能反映硬件的極限轉發能力因為它不受TCP擁塞控制算法的影響。把帶寬目標設置成800M如果實際接收速率遠遠低于800M說明是USB或芯片的瓶頸如果接收速率接近800M但丟包率很高說明芯片有盡力轉發但緩沖區不夠大。網卡鏈路確認這一步也很重要測試前先看協商狀態ethtool eth0確保Speed顯示的是1000Mb/sDuplex是Full。如果顯示100Mb/s先查網線再查對方網卡別帶著百兆鏈路跑測試否則數據沒有參考意義。4.2 實測結果對比與說明我整理了一張簡單的對比表是我這塊板子上的實測數據單板差異可能有但大方向有參考價值。測試項CH398USB 2.0RTL8153BUSB 3.0TCP單線程下行92Mbps940MbpsTCP 4線程下行285Mbps945MbpsUDP下行800M目標296Mbps950MbpsTCP 4線程上行271Mbps938Mbps插入USB 2.0口后的RTL8153B286Mbps約280Mbps從表里能看出兩件事。第一CH398在USB 2.0下確實跑不到千兆實際吞吐在280~300Mbps之間這符合USB 2.0的有效帶寬上限。第二RTL8153B如果插到USB 2.0口上表現和CH398基本一個水平說明這個帶寬瓶頸主要來自USB 2.0協議本身而不是芯片能力。所以如果你判斷一顆芯片好壞不能只看它被插在什么接口上。同樣一顆RTL8153B插USB 3.0口和插USB 2.0口數據能差三倍。很多人在論壇上發帖說“RTL8153B跑不滿千兆”八成是插在了USB 2.0口上。4.3 影響吞吐的4個隱藏因素跑吞吐測試的時候除了芯片本身的規格有4個隱藏因素會明顯影響最終結果這里單獨拉出來說。第一個是USB控制器調度。USB 2.0的總線是共享的如果網卡和一個U盤同時掛在一個HUB上U盤的讀寫會搶占網卡的帶寬導致網卡吞吐量驟降。測試時盡量把網卡插在主機直出的USB口上不要經過HUB。第二個是系統省電策略。Windows默認開啟USB選擇性暫停當系統覺得設備空閑時會自動掛起USB端口。網卡這種設備一掛起再恢復就會出現連接短暫中斷、ping延遲突然飆高的問題。建議在電源選項里把“USB選擇性暫停設置”改為“已禁用”Linux下則建議關閉USB autosuspend。這個坑特別隱蔽我遇到過客戶反饋“網卡用著用著斷一下”最后就是省電策略搞的鬼。第三個是MTU和巨型幀。CH398和RTL8153B都支持1500字節的默認MTU但有些場景追求性能會開啟巨型幀比如MTU 9000。實測中RTL8153B在USB 3.0下開啟巨型幀后CPU占用率會降低但CH398在USB 2.0下開巨型幀收益有限反而可能因為緩沖區設置不當增加延遲。嵌入式場景保持默認MTU更穩妥。第四個是中斷與NAK機制。USB設備在還沒有準備好數據時會回復NAK信號主機需要不斷重試。如果芯片的固件處理不夠好大量NAK會白白消耗總線帶寬。用USBlyzer抓URB時會看到很多NAK如果NAK比例特別高說明芯片的緩沖區太小或者中斷處理不積極。這也是為什么同樣是USB 2.0網卡不同芯片實測吞吐能差出一倍的直接原因。5. 常見問題與排查技巧實錄5.1 設備描述符請求失敗的排查流程“USB設備描述符請求失敗”應該是我被問過最多的問題沒有之一。CH398這種需要裝驅動的芯片在推廣階段尤其容易遇到。我整理了一套排查流程按順序走基本能解決八成問題。第一步換線換口。先把USB線換成50厘米以內、質量靠譜的屏蔽線插到主機后置USB口或者直出的Type-C口上。這一步能排除線纜和前置USB供電不足的問題。第二步看設備管理器里的錯誤碼。如果是錯誤碼43大概率是驅動沒裝對或者設備枚舉失敗。先卸載設備刪除驅動殘留然后按“先裝驅動、后插設備”的順序重新來一遍。第三步用USB抓包工具看枚舉過程。重點看主機有沒有發出SET_ADDRESS請求、設備有沒有正確回應。如果設備完全沒反應檢查芯片供電、D/D-焊接、晶振是否起振。第四步檢查EEPROM內容。有些CH398在出廠時EEPROM里是空的或者內容是錯的會導致設備描述符里的VID/PID不對系統匹配不到驅動。用一個讀卡器或者芯片原廠工具把EEPROM讀出來看一眼確認VID/PID是不是芯片資料里寫的那一串。我在實測中還遇到過一個有趣的情況同一塊板子插Windows能識別插Linux也能識別但插上一臺特定品牌的瘦客戶機就報“設備描述符請求失敗”。后來發現是那臺機器BIOS里的USB設置把“Legacy USB Support”關了進入系統后USB設備枚舉時序異常。跟芯片關系不大屬于主機端兼容性問題。5.2 Linux下網卡時斷時續怎么辦Linux下用CH398網卡最常見的問題不是裝不上而是裝上了以后網絡時斷時續。這種情況優先檢查兩個地方。第一個是USB autosuspend。很多發行版默認開啟USB設備的自動掛起網卡空閑一會兒就進入掛起狀態等下一下數據包過來再喚醒延遲就會飆高甚至斷流。檢查方法cat /sys/bus/usb/devices/1-1/power/control顯示auto就是開啟了自動掛起改成on或者直接關掉整個USB控制器的自動掛起echo on /sys/bus/usb/devices/1-1/power/control echo -1 /sys/module/usbcore/parameters/autosuspend第二個是電源管理驅動的沖突。如果你用的內核版本比較老chip的廠商驅動模塊和內核自帶的usbnet模塊可能同時加載兩個驅動搶同一個設備就會導致接口反復up/down。用lsmod查看加載列表把不需要的模塊列入黑名單。dmesg日志是排查這類問題的第一現場。出現網卡斷連時立刻執行dmesg看最后幾十行有沒有“reset”或“disconnect”相關的信息。我遇到過一種情況日志里頻繁出現“Failed to read register”之類的報錯最后定位是板上3.3V電源在大流量傳輸時電壓跌落導致芯片內部寄存器讀取失敗跟驅動本身無關。5.3 選型前建議做完整驗證清單最后給一份我自己在用的驗證清單打算把CH398用于量產之前建議按這個表逐項過一遍。驗證項通過標準說明USB枚舉Windows/Linux均能穩定識別同一臺設備多次插拔、熱重啟后均正常吞吐穩定性TCP 4線程30分鐘不掉速用iperf3跑長時間壓力觀察掉速和丟包省電策略兼容關閉USB掛起后連續運行24小時不中斷重點關注Windows默認省電策略兼容性矩陣至少5種不同主機芯片組覆蓋Intel、AMD、國產x86、ARM平臺溫升測試滿載1小時后芯片表面溫度可接受網卡在擴展塢里散熱差溫升要提前看EEPROM配置MAC唯一且可量產燒錄批量生產時確認MAC地址寫入流程信號質量USB近端和遠端設備識別均正常線纜較長時確認D/D-信號不劣化驅動安裝包無第三方彈窗和捆綁給客戶交付時驅動包要干凈、簽名完整這份清單不是照著芯片數據手冊抄的而是實際做產品時最容易出問題的環節。尤其是溫升和兼容性這兩個很多工程師容易忽略。USB網卡芯片功耗雖然不大但如果你把它放在一個完全密封的擴展塢里旁邊還有固態硬盤發熱時間久了溫度會累積得很高直接導致PHY芯片誤碼率上升。我這次測試時還發現一個細節CH398的驅動在Windows 11 24H2版本上如果開啟了內核隔離內存完整性首次安裝驅動可能被攔截。需要在Windows安全中心里臨時關閉內核隔離裝完驅動再打開。這個問題不是芯片缺陷但如果你是做產品交付的客戶那臺電腦大概率開著內核隔離最好在說明書里加一句安裝指引。6. 最后再分享一點個人體會這次把CH398和RTL8153從硬件到驅動到實測完整過了一遍我最大的感受是國產替代這件事難點從來不在“換一顆芯片”而在“換完之后整個生態跟不跟得上”。RTL8153強就強在無論是Windows還是Linux還是各種開源系統都有現成驅動和大量踩坑案例出了問題一搜就有答案。CH398要走到那一步還需要時間積累但它本身的硬件底子并不差在USB 2.0的帶寬范圍里完全能穩定干活。如果你手頭項目對帶寬要求不高優先考慮供貨和成本CH398是值得認真測一測的選項。反過來如果你的產品主打“滿速千兆”“NAS高速備份”這類賣點那RTL8153B這類支持USB 3.0的方案仍然是更穩妥的選擇。選型不是比誰參數好看而是比誰在你這套產品里少出問題。芯片是這樣驅動是這樣整個供應鏈也是這樣。 CH398 vs RTL8153：USB轉千兆網卡替代實測與驅動適配全記錄
USB轉千兆網卡這個品類過去十幾年基本是瑞昱RTL8153家族的地盤。輕薄本擴展網口、擴展塢的RJ45、工控機調試網口一插就到手Windows下免驅、Linux下r8152直接識別成熟得像街頭便利店。但這兩年越來越多的選型表上加了一行“國產化比例”于是CH398這顆國產USB轉千兆網卡控制芯片開始頻繁出現在替代清單里。這篇文章把我最近一次把CH398和RTL8153真刀真槍對比的過程完整記錄下來從原理圖、驅動適配、USB枚舉抓包一直寫到iperf3吞吐實測和踩坑清單適合硬件工程師、嵌入式開發以及做選型替代的采購同學參考。1. 為什么現在要把CH398拿出來跟RTL8153比1.1 國產化需求怎么落到USB轉網卡這顆料上先說個挺現實的事。以前做產品選型誰都不會專門去關心一顆USB轉網卡芯片的供貨渠道。RTL8153交期穩定、價格透明、文檔齊全整機廠直接照著參考設計畫板子就行。但最近兩三年供應鏈端的變化讓很多人意識到一顆不起眼的小芯片如果供貨卡住整條產線都得停下來等。于是“國產替代”這件事就從一個采購KPI變成了硬件工程師案頭的實際工作。而這種USB轉網卡芯片恰恰是替換的高頻對象用量不大、功能相對固定、國產廠商做得也不差替換成本比主控、電源管理這些核心芯片低很多。CH398能在這種背景下被提出來跟RTL8153比首先是市場有這個需求其次才是芯片本身參數能不能打。我這次拿到的樣片是CH398主要對比對象是RTL8153B。測試場景覆蓋了三個典型應用Windows筆記本擴展塢上的有線網口、Linux工控機上的冗余調試口、還有一顆放在樹莓派上做獨立千兆網卡用。基本能代表這塊芯片最常見的去處。1.2 CH398和RTL8153在定位上的真實差異先說一個很多人容易忽略的點同樣是“USB轉千兆網卡”USB接口跑在什么速率直接決定了這顆芯片能不能跑滿千兆。我手上這顆CH398樣片走的是USB 2.0 High-Speed通道也就是480Mbps的理論總線速率。RTL8153B則支持USB 3.0/3.2 Gen1理論帶寬5Gbps所以RTL8153B在USB 3.0口上能比較輕松地把千兆跑滿。而CH398如果走USB 2.0哪怕PHY和MAC都是千兆的實際吞吐也會被USB 2.0的總線帶寬卡住這屬于物理層面的限制驅動怎么調都突破不了。但話要說回來。很多實際場景并沒有跑滿千兆的需求。工控機調試、產線燒錄、嵌入式設備聯網需要的往往是“穩定能用的百兆以上帶寬”而不是持續千兆打滿。CH398在這種場景下規格上是夠用的而且外圍電路、功耗、成本都有優勢。選型的第一步是先想清楚你的產品到底需要多少帶寬而不是盯著“千兆”這兩個字就覺得必須跑滿。注意如果你看到一顆芯片標著“千兆網卡”先去看它USB接口是USB 2.0還是USB 3.0。USB 2.0的千兆網卡大概率實際吞吐在300Mbps上下這在很多場景夠用但別拿它去做NAS滿速傳輸。2. 硬件設計原理圖上那幾處必須盯住的地方2.1 從RTL8153換到CH398外圍要改什么如果你已經有成熟的RTL8153方案想把主控換成CH398建議的路徑不是直接替換而是把原理圖打開對照芯片手冊逐項過一遍。我這次改板子時主要動了這幾處第一是晶振。RTL8153B和CH398用的都是25MHz無源晶振這點可以直接沿用但晶振的負載電容值要按芯片手冊推薦值重新確認。我一開始偷懶照抄了原方案的18pF結果芯片插上后USB能枚舉但網口鏈路協商不穩定后來換回手冊推薦的12pF負載電容的晶振問題就消失了。晶振這地方看起來簡單實際上直接影響PHY的時鐘精度而PHY對時鐘抖動又很敏感。第二是EEPROM。RTL8153B方案里經常會配一顆93C46或者24C02之類的EEPROM用來存MAC地址和配置信息。CH398如果只在Windows下當普通網卡用不寫EEPROM也能工作芯片會用自己的默認配置上電。但如果你需要固定MAC地址、需要量產時每臺設備不同MACEEPROM這部分就得保留并確認芯片手冊里的I2C/SPI地址映射關系。第三是網絡變壓器和RJ45。這倆基本是通用的只是要注意CH398的PHY側中心抽頭接法。有些國產芯片的PHY內部已經有偏置網絡變壓器的中心抽頭可以直接接電源或者通過電容接地具體接法以手冊里的參考電路為準。我遇到過因為照抄其他方案導致link燈常亮但不能通信的情況最后就是中心抽頭供電沒接對。第四是電源紋波。USB轉網卡芯片在工作時電流變化很快特別是傳輸大流量數據時3.3V電源上的紋波會明顯變大。我實測CH398在滿載發送時如果LDO選得不好紋波能到50mV以上這時候丟包率會上升。建議在芯片電源引腳附近放一組10uF100nF的去耦電容不要省。2.2 Type-C口和USB差分線的那些坑現在很多擴展塢和網卡都直接做Type-C接口這里有兩個很容易踩的坑。一個是Type-C的CC引腳。如果你是按照傳統USB-A口的方案畫的板子直接接到Type-C座上大概率插上去沒反應。Type-C接口在作為device也就是被主機供電的設備時CC1和CC2引腳必須各放一顆5.1k下拉電阻到地主機才能識別到設備插入并輸出5V。這個點其實在很多USB相關的調試場合都會出現不只是網卡芯片我之前幫朋友查過一個Type-C轉串口板子不識別的問題最后也是CC引腳懸空導致的。另一個是D/D-差分走線。USB 2.0雖然速率不算極高但D/D-這兩根線的差分阻抗還是建議控制在90歐姆左右長度盡量短遠離時鐘線和電源走線。很多畫板的人覺得USB 2.0無所謂隨便走走就行實際做出來的板子在USB 3.0主機上可能沒問題但在老舊的USB 2.0 HUB上就經常出現“設備描述符請求失敗”。另外D/D-上的對地電容在芯片資料里如果沒有特別說明一般不需要額外加加了反而會影響信號邊沿導致眼圖閉合。如果你把網卡放在擴展塢內部還要注意USB線纜到Type-C座之間的路徑。擴展塢內部走線復雜D/D-如果穿過好幾層板、過了連接器信號質量會明顯下降。這種場景能選帶有信號完整性優化功能的芯片會省心很多但CH398本身更偏向簡單直接的方案所以布局上要自己多花點心思。3. 驅動適配與USB枚舉抓包3.1 Windows和Linux下的驅動適配路線硬件畫好、板子貼出來下一步就是接上電腦看能不能識別。這一步是決定替代方案能不能落地的關鍵也是CH398跟RTL8153差異最大的地方。RTL8153在Windows下有微軟WHQL認證驅動插上就自動裝好設備管理器里顯示“Realtek USB GbE Family Controller”。Linux內核里的r8152驅動也很成熟直接編譯進內核插上就生成ethX接口。CH398就沒有這么省心了Windows下第一次插入系統大概率會直接重枚舉成一個帶問號的未知設備需要手動安裝廠商提供的驅動包。我這次測試用的驅動是廠商隨樣片一起給到的安裝包里有Windows 7/8/10/11的x86和x64版本。安裝過程本身沒什么難度但有一點必須提醒安裝驅動之前不要先插設備先裝好驅動再插USB或者按安裝包要求的順序來否則容易留下一個驅動殘留導致后面怎么插都識別成“未知USB設備”。Linux下的適配路徑有兩種。如果CH398走的是標準的CDC-ECM或者RNDIS協議那么主流的發行版內核都能直接識別插上之后會出現usb0之類的接口。如果芯片走的是廠商私有協議那就需要廠商提供Linux驅動源碼自己編譯DKMS模塊。我拿到的這個版本就不是標準CDC類所以Linux下必須裝驅動模塊。裝完之后我建議把模塊加入開機加載列表否則每次重啟都要手動modprobe。這里給個判斷小技巧插上設備后先在Windows設備管理器里看它枚舉出來的設備類。如果顯示“網絡適配器”說明系統是用廠商INF驅動來匹配的如果顯示“USB Composite Device”或者“CDC”那說明走的是系統通用類驅動。Linux下可以用lsusb查看設備的bInterfaceClass如果是0x02Ethernet Networking或0x0ACDC Data大概率能被系統通用驅動認到。3.2 用USB抓包工具把“看不見的設備”揪出來驅動裝不上的時候最容易讓人摸不著頭腦。設備管理器里一直顯示“設備描述符請求失敗”而且代碼是43怎么看都不像芯片壞了可系統就是不認。這種問題建議直接用USB抓包工具看枚舉過程而不是盲目換驅動、換線、換電腦。Windows下我常用的是USBPcap配合Wireshark或者用USBlyzer這種商業工具。USBlyzer能直接看到設備枚舉時的每一步狀態包括Reset、SetAddress、Get Descriptor、Set Configuration這些請求。如果發現主機發送了GET_DESCRIPTOR請求但設備一直沒有回復那就說明芯片沒有正常上電或者D上拉電路有問題。USB協議這塊簡單說兩句。USB 2.0設備枚舉時最關鍵的一步是D或D-引腳上的上拉電阻。全速設備在D上拉1.5k到3.3V低速設備則在D-上拉主機檢測到這個電平變化才知道有設備插入然后才開始枚舉流程。如果芯片內部已經集成了上拉電阻那外部就不用再放如果外部自己加了一顆上拉導致上拉電平、阻值和內部電路并聯沖突設備反而可能識別不正常。我這次實測時就遇到過一個很隱蔽的問題板子在自研主板上識別正常但接到電腦前置USB口上就“設備描述符請求失敗”。用USB抓包一看發現是線材太長、D信號上升沿太差主機在高速握手階段失敗。后來把線纜從1.5米換成0.5米的屏蔽線問題直接消失。這種問題如果不抓包純靠換驅動能折騰你一下午。提醒USB抓包不是只能看枚舉故障。設備正常工作后還可以抓BULK IN/OUT端點的URB確認數據交互是否繁忙、有沒有頻繁的NAK重試。這對排查“網卡吞吐上不去”非常有用。4. 吞吐量實測CH398到底能跑多少4.1 iperf3測試環境與命令驅動裝好、接口up起來下一步就是跑吞吐量。這個環節不能省芯片標稱“千兆”實際能跑多少得用數據說話。我這次搭的測試環境是這樣被測設備是一臺裝了CH398網卡的Linux工控機另一臺是裝了RTL8153B USB網卡的Windows筆記本兩臺設備通過六類網線直連中間不經過交換機。測試軟件用iperf3工控機上跑服務端筆記本上跑客戶端。先交代一下測試命令方便你直接抄Windows筆記本作為發送端iperf3 -c 192.168.1.10 -t 30 -P 4 -i 1這條命令的意思是向服務端發起TCP流量測試持續30秒用4個并行連接每1秒打印一次結果。并行連接數很重要單線程TCP往往跑不滿帶寬多線程才能壓出真實水平。UDP測試用下面這條iperf3 -c 192.168.1.10 -t 30 -u -b 800M -i 1UDP測試能反映硬件的極限轉發能力因為它不受TCP擁塞控制算法的影響。把帶寬目標設置成800M如果實際接收速率遠遠低于800M說明是USB或芯片的瓶頸如果接收速率接近800M但丟包率很高說明芯片有盡力轉發但緩沖區不夠大。網卡鏈路確認這一步也很重要測試前先看協商狀態ethtool eth0確保Speed顯示的是1000Mb/sDuplex是Full。如果顯示100Mb/s先查網線再查對方網卡別帶著百兆鏈路跑測試否則數據沒有參考意義。4.2 實測結果對比與說明我整理了一張簡單的對比表是我這塊板子上的實測數據單板差異可能有但大方向有參考價值。測試項CH398USB 2.0RTL8153BUSB 3.0TCP單線程下行92Mbps940MbpsTCP 4線程下行285Mbps945MbpsUDP下行800M目標296Mbps950MbpsTCP 4線程上行271Mbps938Mbps插入USB 2.0口后的RTL8153B286Mbps約280Mbps從表里能看出兩件事。第一CH398在USB 2.0下確實跑不到千兆實際吞吐在280~300Mbps之間這符合USB 2.0的有效帶寬上限。第二RTL8153B如果插到USB 2.0口上表現和CH398基本一個水平說明這個帶寬瓶頸主要來自USB 2.0協議本身而不是芯片能力。所以如果你判斷一顆芯片好壞不能只看它被插在什么接口上。同樣一顆RTL8153B插USB 3.0口和插USB 2.0口數據能差三倍。很多人在論壇上發帖說“RTL8153B跑不滿千兆”八成是插在了USB 2.0口上。4.3 影響吞吐的4個隱藏因素跑吞吐測試的時候除了芯片本身的規格有4個隱藏因素會明顯影響最終結果這里單獨拉出來說。第一個是USB控制器調度。USB 2.0的總線是共享的如果網卡和一個U盤同時掛在一個HUB上U盤的讀寫會搶占網卡的帶寬導致網卡吞吐量驟降。測試時盡量把網卡插在主機直出的USB口上不要經過HUB。第二個是系統省電策略。Windows默認開啟USB選擇性暫停當系統覺得設備空閑時會自動掛起USB端口。網卡這種設備一掛起再恢復就會出現連接短暫中斷、ping延遲突然飆高的問題。建議在電源選項里把“USB選擇性暫停設置”改為“已禁用”Linux下則建議關閉USB autosuspend。這個坑特別隱蔽我遇到過客戶反饋“網卡用著用著斷一下”最后就是省電策略搞的鬼。第三個是MTU和巨型幀。CH398和RTL8153B都支持1500字節的默認MTU但有些場景追求性能會開啟巨型幀比如MTU 9000。實測中RTL8153B在USB 3.0下開啟巨型幀后CPU占用率會降低但CH398在USB 2.0下開巨型幀收益有限反而可能因為緩沖區設置不當增加延遲。嵌入式場景保持默認MTU更穩妥。第四個是中斷與NAK機制。USB設備在還沒有準備好數據時會回復NAK信號主機需要不斷重試。如果芯片的固件處理不夠好大量NAK會白白消耗總線帶寬。用USBlyzer抓URB時會看到很多NAK如果NAK比例特別高說明芯片的緩沖區太小或者中斷處理不積極。這也是為什么同樣是USB 2.0網卡不同芯片實測吞吐能差出一倍的直接原因。5. 常見問題與排查技巧實錄5.1 設備描述符請求失敗的排查流程“USB設備描述符請求失敗”應該是我被問過最多的問題沒有之一。CH398這種需要裝驅動的芯片在推廣階段尤其容易遇到。我整理了一套排查流程按順序走基本能解決八成問題。第一步換線換口。先把USB線換成50厘米以內、質量靠譜的屏蔽線插到主機后置USB口或者直出的Type-C口上。這一步能排除線纜和前置USB供電不足的問題。第二步看設備管理器里的錯誤碼。如果是錯誤碼43大概率是驅動沒裝對或者設備枚舉失敗。先卸載設備刪除驅動殘留然后按“先裝驅動、后插設備”的順序重新來一遍。第三步用USB抓包工具看枚舉過程。重點看主機有沒有發出SET_ADDRESS請求、設備有沒有正確回應。如果設備完全沒反應檢查芯片供電、D/D-焊接、晶振是否起振。第四步檢查EEPROM內容。有些CH398在出廠時EEPROM里是空的或者內容是錯的會導致設備描述符里的VID/PID不對系統匹配不到驅動。用一個讀卡器或者芯片原廠工具把EEPROM讀出來看一眼確認VID/PID是不是芯片資料里寫的那一串。我在實測中還遇到過一個有趣的情況同一塊板子插Windows能識別插Linux也能識別但插上一臺特定品牌的瘦客戶機就報“設備描述符請求失敗”。后來發現是那臺機器BIOS里的USB設置把“Legacy USB Support”關了進入系統后USB設備枚舉時序異常。跟芯片關系不大屬于主機端兼容性問題。5.2 Linux下網卡時斷時續怎么辦Linux下用CH398網卡最常見的問題不是裝不上而是裝上了以后網絡時斷時續。這種情況優先檢查兩個地方。第一個是USB autosuspend。很多發行版默認開啟USB設備的自動掛起網卡空閑一會兒就進入掛起狀態等下一下數據包過來再喚醒延遲就會飆高甚至斷流。檢查方法cat /sys/bus/usb/devices/1-1/power/control顯示auto就是開啟了自動掛起改成on或者直接關掉整個USB控制器的自動掛起echo on /sys/bus/usb/devices/1-1/power/control echo -1 /sys/module/usbcore/parameters/autosuspend第二個是電源管理驅動的沖突。如果你用的內核版本比較老chip的廠商驅動模塊和內核自帶的usbnet模塊可能同時加載兩個驅動搶同一個設備就會導致接口反復up/down。用lsmod查看加載列表把不需要的模塊列入黑名單。dmesg日志是排查這類問題的第一現場。出現網卡斷連時立刻執行dmesg看最后幾十行有沒有“reset”或“disconnect”相關的信息。我遇到過一種情況日志里頻繁出現“Failed to read register”之類的報錯最后定位是板上3.3V電源在大流量傳輸時電壓跌落導致芯片內部寄存器讀取失敗跟驅動本身無關。5.3 選型前建議做完整驗證清單最后給一份我自己在用的驗證清單打算把CH398用于量產之前建議按這個表逐項過一遍。驗證項通過標準說明USB枚舉Windows/Linux均能穩定識別同一臺設備多次插拔、熱重啟后均正常吞吐穩定性TCP 4線程30分鐘不掉速用iperf3跑長時間壓力觀察掉速和丟包省電策略兼容關閉USB掛起后連續運行24小時不中斷重點關注Windows默認省電策略兼容性矩陣至少5種不同主機芯片組覆蓋Intel、AMD、國產x86、ARM平臺溫升測試滿載1小時后芯片表面溫度可接受網卡在擴展塢里散熱差溫升要提前看EEPROM配置MAC唯一且可量產燒錄批量生產時確認MAC地址寫入流程信號質量USB近端和遠端設備識別均正常線纜較長時確認D/D-信號不劣化驅動安裝包無第三方彈窗和捆綁給客戶交付時驅動包要干凈、簽名完整這份清單不是照著芯片數據手冊抄的而是實際做產品時最容易出問題的環節。尤其是溫升和兼容性這兩個很多工程師容易忽略。USB網卡芯片功耗雖然不大但如果你把它放在一個完全密封的擴展塢里旁邊還有固態硬盤發熱時間久了溫度會累積得很高直接導致PHY芯片誤碼率上升。我這次測試時還發現一個細節CH398的驅動在Windows 11 24H2版本上如果開啟了內核隔離內存完整性首次安裝驅動可能被攔截。需要在Windows安全中心里臨時關閉內核隔離裝完驅動再打開。這個問題不是芯片缺陷但如果你是做產品交付的客戶那臺電腦大概率開著內核隔離最好在說明書里加一句安裝指引。6. 最后再分享一點個人體會這次把CH398和RTL8153從硬件到驅動到實測完整過了一遍我最大的感受是國產替代這件事難點從來不在“換一顆芯片”而在“換完之后整個生態跟不跟得上”。RTL8153強就強在無論是Windows還是Linux還是各種開源系統都有現成驅動和大量踩坑案例出了問題一搜就有答案。CH398要走到那一步還需要時間積累但它本身的硬件底子并不差在USB 2.0的帶寬范圍里完全能穩定干活。如果你手頭項目對帶寬要求不高優先考慮供貨和成本CH398是值得認真測一測的選項。反過來如果你的產品主打“滿速千兆”“NAS高速備份”這類賣點那RTL8153B這類支持USB 3.0的方案仍然是更穩妥的選擇。選型不是比誰參數好看而是比誰在你這套產品里少出問題。芯片是這樣驅動是這樣整個供應鏈也是這樣。