概述
快速检测线、半导体工厂、智能交通系统、运动分析和容积捕捉等多种视觉系统应用场景都需要高分辨率、高 FPS 和高数据传输率来达到更好的结果。对于希望利用帧率更快和分辨率更高的机器视觉摄像头来改进输出的视觉系统工程师来说，从 1GigE 升级到 10GigE 是显而易见的选择。然而，根据 AIA（自动成像协会）的研究，其采用相当缓慢。考虑到这种升级带来的三个技术挑战：可靠性（丢包）、高 CPU 使用率和高延迟，这一点可以理解。本文介绍了 Teledyne FLIR Oryx + Myricom 捆绑解决方案如何解决这些挑战。
更新 1：完美的性能
虽然 10GigE Vision 的带宽比 GigE Vision 协议高 10 倍，但 10GigE 主机适配器性能却并未相应提高。从摄像头向主机的数据传输通常会导致 CPU 过载，造成应用程序缓冲区溢出，以及对于要求苛刻的应用程序而言不可接受的丢包水平。
通过利用主机适配器直接在卡上处理数据包接收和图像重建，CPU 就不再需要管理这些任务。Teledyne FLIR Oryx + Myricom 捆绑解决方案专为应对此类情况而设计。如我们下方的测试结果所示，系统可靠性可大幅提高，从而显著减少丢包，进而减少丢帧。
该捆绑解决方案可与我们全新的定制 SDK 驱动程序无缝结合，专门用于处理 Myricom 卡提供的数据。通过这种组合，可以完美、可靠地将图像数据从摄像头传输到主机 PC 上。检测结果见下方附录：可靠性和 CPU 使用率测试。
Teledyne FLIR Oryx + Myricom 捆绑解决方案的高性价比使其成为显而易见的选择；与分别购买硬件再集成相比，这是一种经济实惠且高度可靠的设置。
更新 2：CPU 使用率可管理
理论上，CPU 最高可以用一个内核的 100% 来处理从 10GigE 接入的输入数据，并且在运行多个应用程序/摄像头时可以使用多个内核。通过使用 Myricom 卡来管理数据包接收和图像重建，每个应用程序的 CPU 使用率可以低至 1%，从而可以将更多的 CPU 周期用于图像处理。检测结果见下方附录：可靠性和 CPU 使用率测试
更新 3：延迟缩短
10GigE Vision 的帧延迟不是确定的；这意味着帧的到达可能伴随显著的时基抖动。在某些情况下，特别是对于交换机，不仅存在丢包，有时帧的接收会出现逆序现象。Teledyne FLIR Oryx + Myricom 捆绑解决方案通过及时通知帧完成以缩短延迟，以及减少时基抖动来解决这个问题。
附录：可靠性和 CPU 使用率测试
测试 1：高带宽 7 天串流
使用通过 Teledyne FLIR Spinnaker API 创建的定制控制台应用程序，设置由 890 万像素 Teledyne FLIR Oryx 摄像头来连续捕捉图像，并跟踪任何不完整的图像，无额外的处理或第三方资源密集型程序同时运行。
测试结果：采集约 4000 万帧图像；检测到 0 帧不完整/丢失的图像。
注：在整个 7 天的测试期间检查了 CPU 使用率，发现始终保持在 1%。在停用新的 Myricom 驱动程序，仅依靠 FLIR 标准滤波器驱动器的情况下，专门用于应用程序的 CPU 核心的 CPU 使用率保持在大约 100% 的水平。
测试 2：双摄像头串流
该测试包括在同一定制控制台应用程序中运行的两台 Oryx 摄像头（ORX-10G-123S6M 和 ORX-10G-89S6C），每台摄像头的带宽为 6.7 Gb/s，连续运行 24 小时。
测试结果：每个摄像头采集约 600 万帧图像；检测到 0 帧不完整/丢失的图像
测试 3：24 小时 CPU 压力测试
该测试包括一台 Oryx 摄像头（ORX-10G-123S6M），其设置与测试 1 相同。
使用了与测试 1 相同的控制台应用程序，但这次同时使用了另一个应用程序；该定制应用程序旨在模拟高工作负荷，CPU 的总使用率约为 90%（所有八个内核）。
测试结果：采集约 600 万帧图像；检测到 0 帧不完整/丢失的图像
测试系统硬件和软件规格：
i7-9700k @ 3.6GHz | 16GB | Windows 10 1809
Teledyne FLIR Spinnaker 2.1.0.82 和 PGRLwf 2.7.3.397 与带 Myricom 支持的定制 2.3.0.x 版本
