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的方案仍然是更稳妥的选择。选型不是比谁参数好看而是比谁在你这套产品里少出问题。芯片是这样驱动是这样整个供应链也是这样。
