诊断 GigE 丢包，且不掩盖故障

本测试要回答的问题

把图像传输不完整，与漏触发和应用程序队列丢失区分开来。仅靠帧计数器无法判断是哪一层出了问题。

这是一份与厂商无关的现场调试方法。更改任何设置之前，请先查阅所用具体型号的相机、镜头、传感器或控制器手册。文中的数值示例表为假设数据，既不是 Deyi Vision 的测量结果，也不是产品规格。

前置条件

使用量产时的像素格式、ROI 和触发方式。打包格式和 chunk 数据都会改变有效载荷；应采用相机报告的有效载荷大小，而不是凭猜测的每像素字节数。

只有先分清漏触发与不完整的网络图像，才能开始测试。应用程序日志里缺少某个工件，也可能是处理失败或文件写入失败。确认现场的相机和接收端提供哪些计数器，并根据该型号的手册记下它们的定义。不要把不相关的超时当作丢包计数器来推断。更改网卡、数据包大小或驱动选项之前，先保留出现故障时的原始配置。

测试台与记录

准备专用的 NIC 路径、确认完好的线缆，以及数据流、NIC 和应用程序计数器的日志。更改任何内容之前，先记录驱动、交换机、MTU、数据包大小、帧率和 CPU 负载。

画出从相机经线缆和交换机到主机网卡的完整路径。记录每一段所支持的 MTU、链路速率、网卡标识、流参数、图像尺寸、像素打包方式和已启用的处理。准备一份运行日志，写明预期触发数、收到的帧 ID、不完整图像数、相机报告的重传统计、已处理的结果和已保存的文件。为每次运行使用专门的运行标识，避免计数器复位或接收端重启之后，不相关的几次运行被悄悄合并在一起。

执行测试

1. 让一台相机直连主机，采用保守且受支持的数据包大小，按 10000 个预期帧的量记录日志。
2. 按时间段对照触发计数、相机帧 ID、完整接收的帧和已处理的结果。
3. 每次只改变一个变量：线缆、数据包大小或包间延迟；并核实整条路径上的 MTU 是否兼容。
4. 逐步加回交换机和其他相机；再带着量产时的磁盘写入和 CPU 负载重复测试。

先在不做检测处理、不写磁盘的情况下接收图像，数据包大小采用保守且受支持的值，相机采集设置与出故障的那次运行相同。运行前后各读取一次计数器，然后把处理和存储分别加回去。两次运行之间只改动一项传输设置；如果它没有改善所观察到的故障，就恢复原先的设置。可重复的改善，比一次偶然干净的短时采集更有说服力。

假设示例表

假设 2048 × 1536 像素的 Mono8 图像以 30 fps 传输，需要 94.37 MB/s 的有效载荷。以太网开销和重传还要另外占用带宽，所以这并不能证明链路余量充足。

payload_rate = payload_bytes * frames_per_second
2048 * 1536 * 1 * 30 = 94371840 B/s
= 94.37 MB/s = 754.97 Mbit/s (payload only)

示例表只估算图像有效载荷。协议头、数据包重传以及共用链路的其他设备都会占用额外的容量，所以有效载荷低于标称链路速率，并不能证明余量充足。使用每像素字节数之前，先确认所选格式是打包的还是补位的。把预期帧数与后续每一级的计数逐级核对；第一个计数不一致的环节，指明了下一步该查哪里，但并不会自动证明其根本原因。

测试流程

解读证据

按分级示意图，从采集一直读到结果。如果相机的帧 ID 在递增、完整的图像却没有到达，就要查传输和接收端的处理。如果完整图像到达了、却没有结果，就检查队列的所有权和处理异常。如果有结果、文件却缺失，就检查存储。计数器和有代表性的日志都要保留：来自另一帧的、看起来正确的图像，并不能解释丢失的那一帧。

故障排查

• 重传次数上升且伴随 NIC 错误，提示传输方面有问题；检查线缆和整条链路。
• 完整接收而处理结果缺失，说明队列或处理已经过载。增加缓冲区也许只能推迟溢出，并不能解决吞吐量问题。

只有启用磁盘写入之后才出故障，提示主机资源争用，但应关闭存储再重复测试来加以确认。数据包调大之后接收反而变差，可能暴露了路径中存在不兼容的环节；应逐跳检查，而不是不加区分地开启巨型帧。增大包间延迟可以缓解突发压力，但会拉长传输时间。要用实际型号检查由此得到的吞吐量和采集行为，不要想当然地认为原来的帧率仍能达到。

验收与交接

要求在约定的整个运行期间（包括峰值负载下），各级帧数一致，且没有无法解释的不完整图像。写明运行时长和观察到的重传次数；一次干净的短时运行并不能证明系统在任何情况下都可靠。

将原始文件、设置、样品标识和判定限值一并归档。请参照下方相关的产品指南与准备指南，与 Deyi Vision 讨论已有文档记录的需求。

用最终设置重复约定的量产工作负载，包括处理、存储和其他预期会出现的网络流量。对整个预期运行期间的各级计数逐级核对，并明确记录所允许的丢失策略。只有在生产安全允许时，才加入受控的接收端重启或线缆恢复测试，并验证不完整的帧是如何被拒收的。发布配置时，要同时交付网络拓扑、计数器定义，以及证明预期工作负载可持续运行的证据。