硬件:
- 源自红杉平台(AMCC)
- 使用AMCC PowerPC 440EPx和
- Marvell 88E1111以太网PHY, 256 M DDR2 RAM Linux版本2.6.24.2
在linux应用程序(C语言)中，我通过udp套接字传输数据，每秒约60MB。有时我的pc测试程序注意到一个丢失的数据包，因为所有的数据包都被编号(GigE视觉流通道协议)。我知道udp协议不可靠。但是因为我有干净的劳动条件并且它总是相同的最后一个数据包丢失，我认为这一定是系统错误在我的代码中的某个地方。
所以我试图找出丢失包的原因超过一个星期，但我找不到它。
以下问题:
- 使用Jumbo-Frames:数据包大小为8K Bytes
- 总是相同的最后一个数据包丢失
- 错误是罕见的(经过几个小时和数千传输图像)
- 在网卡上连接或重新连接设备后(自动协商后)错误率更高
I tried:
- 使用其他网卡
- 检查我的代码:检查函数返回值，检查函数的错误处理
- 记录我的设备上的传出包
- 使用wireshark工具查看包，并检查日志来自设备 的包
我怎样才能解决这个问题?我知道这很难，因为失败的原因有很多可能性。
问题:
- linux 2.6.24以太网驱动程序栈有已知的bug吗?特别是在自动协商之后)，这是后来固定的版本?
- 我应该在传输套接字上设置特殊选项吗?(袜子= socket(AF_INET, SOCK_DGRAM, 0);
- 自动协商后需要更新套接字吗?
- 我应该在linux内核中启用任何linux诊断消息来找出问题所在吗? 有其他建议吗?
我曾经开发过一个类似的应用程序，其中连接的一端是windows，另一端是嵌入式实时操作系统(不是linux)，两者之间唯一的东西是cat5以太网电缆。事实上，我发现大量UDP消息几乎总是会导致其中一条消息丢失，而且总是同一条消息。非常奇怪，在用了wireshark和其他网络工具很多时间之后，我最终决定，这只能是UDP不可靠的事实。
我的建议是切换到TCP并构建一个小的消息帧:
http://blog.chrisd.info/tcp-message-framing/我发现使用TCP是非常可靠的，如果流量是"流"(意思是:主要是单向的)，它也可以非常快。另外，在TCP之上构建一个消息帧比在UDP之上构建TCP要容易得多。
这可能是相机的问题——令人惊讶的是，即使在相机方面，GigE视觉也可能比CameraLink等竞争技术更复杂，更不确定。特别是，我看到了我自己的奇怪问题，并从制造商那里得知，许多相机都有一些已知的缓冲问题，特别是在更高的分辨率/帧率下运行时。
检查你的相机固件和供应商，看看是否有更新来解决这个问题。
或者，也许你有一些延迟之间的最后一个数据包recvmsg和前一个recvmsg，如处理帧数据之前接收gvsp帧数据包的结束?
附加建议:确保在系统和摄像机之间没有交换机或其他网络设备-使用直接的Cat-6e电缆。