技术门户

技术门户

GigE 视觉相机的 UDP、TCP 和 RDMA

GigE 视觉 + GVSP

  • 15 年以上的广泛使用
  • 完全认可和成熟的标准
  • 大规模采用
  • 基于UDP的协议
  • 真正的流媒体协议
  • 组播支持
  • 拥有你需要的一切
  • 需要正确设计的高速接收器

我们将花点时间了解 GigE Vision 背后的技术。 GVSP 是当前标准中使用的以太网流协议。 流由多个帧(或图像)组成。 每个帧由一个前导数据包、多个图像(或有效负载)数据包和一个尾部数据包组成。 所有数据包都遵循 UDP 以太网协议,这是一种未连接的协议。 这只是意味着相机发送数据包并让接收器完成将数据放入目标缓冲区的工作。 作为一个未连接的协议,这意味着它的网络开销为 0,从而实现最大的网络性能。 这也意味着支持多播等基础知识。 我们必须正确设计接收器以避免数据丢失。 CXP 也遵循相同的协议,并让接收方完成将数据放入目标缓冲区的工作。 这导致高质量接收器的最佳性能和最低延迟和抖动。 我们会注意到,一些公司无法设计出高质量的接收器,这导致他们走上了替代道路。

15 年以上的广泛使用

图:GVSP 帧和数据包结构。

传统 GigEVision + GVSP

  • 需要内存复制(软件中的标头拆分)
  • 更高的 CPU 百分比
  • 3 倍系统内存带宽
  • 3 倍更强大的 PC
  • 3x PC 数量
  • 1/3 系统密度
  • 需要精心设计的高速接收器

传统的 GVSP 在软件中使用标头拆分 从 GVSP 数据包中剥离标头并将 有效负载数据包中的图像数据放入连续的内存缓冲区。 这个过程会提高 CPU 使用率,但更重要的是会消耗 与 3 副本实现相比,系统内存带宽使用量增加了 0 倍。 这导致系统效率为 33%,其中因素 以多种方式进入系统成本。 这是一个设计不佳的接收器的例子,市场上有很多 即使在 10GigE 上仍在这样做,但我们仍然看到一些情况 公司难以在单个服务器中运行多个 1GigE 摄像头 所有这些都与糟糕的接收器设计有关。

需要内存复制(软件中的标头拆分)

图:传统 GigEVision + GVSP 实施中的数据路径。

优化的 GigEVision + GVSP

  • 真正的零拷贝
  • 在 OTS NIC 中使用标头拆分 (HS)
  • 完全内核绕过
  • M&E 市场中用于 SMPTE 2110 的 HS
  • 行业加工卡支持
  • 最低延迟和抖动
  • 质量实施不需要(也不需要)重新发送或流量控制
  • 保持 GigEVision 兼容

优化的 GVSP 在 OTS 性能 NIC 和其他处理设备中可用的硬件中使用标头拆分。 这与 SMPTE 2110 在大规模 M&E 市场中使用的方法相同,对数据丢失的容忍度也为 0。 在这个市场上,他们依赖于设计良好的接收器,因此 OTS NIC 提供标头拆分技术,用于 SMPTE 2110 等流媒体实现,以及 RDMA/RoCE 等消息和连接协议。 我们与支持 RDMA/RoCE 的相同供应商合作,使用标头拆分来实现功能最丰富和性能最高的接收器,同时遵守当前和高度成熟的 GigEVision 规范。

GigEVsion 优化实施中的数据路径。
Emergent Vision Technologies 的合作伙伴。

图(上):GigEVsion 优化实施中的数据路径。
图(下):Emergent Vision Technologies的合作伙伴。

GigEVision + TCP(尝试 #1)

  • 建议添加 GigEVision 标准
  • *完全专有*直到批准(可能在 2 年内)
  • 基于TCP的协议
  • 开销使性能低于 UDP
  • 不是零拷贝技术(3x mem bw)
  • 使用重新发送/流量控制作为拐杖
  • 不是流媒体协议(如 USB)
  • 严格点对点(如 USB/CXP)
  • 不支持多播(如 USB/CXP)
  • 不支持 GPUDirect

一些供应商在实施或实现性能方面遇到报头分割技术的问题,因此他们寻找其他解决方案。有些还尝试依赖成本非常低的 NIC,甚至是低性能的主板驻留芯片,这对于晶圆处理等应用来说是危险的,如果发现问题,会导致高额罚款。一项建议是使用 TCP。与 UDP 相比,这种连接协议的优势有限。 TCP 提供重发和流量控制以实现更可靠的传输,但这会影响性能并导致延迟和抖动。 TCP 仍然需要数据副本,并且由于它是一个连接协议,因此它具有开销,这抵消了将摄像机添加到系统中时可靠传输的优势。对于性能较低但运行很多的系统来说这可能没问题 千兆以太网相机 在单个系统上很难提供有保证的性能。即使没有硬件报头分割,基于 UDP 的正确设计和裕度系统也能达到同样的效果。除非系统设计良好且裕量充足,否则性能永远无法得到保证。

CXP 不使用重新发送和流量控制,并具有最佳的接收性能、​​延迟和抖动。 那么为什么 GigE Vision 需要这个:
原因之一是某些 NIC 卡上的物理缓冲不足——无法应对操作系统的波动。 另一个是 BER 性能差。

好消息是高质量的 NIC 有足够的物理缓冲,比如 CXP 来处理这个问题。 坦率地说,BER 只是设计非常糟糕的低成本产品中的一个问题。

但是,现实情况是,在所有情况下,正确调整的服务器(包括 BIOS 更改以及正确编写的接收器代码)都很重要。

一旦数据进入系统内存,您将如何处理这些数据?

图:GigE Vision + TCP 实现向前 1 步,向后 2 步。

GigE Vision + RDMA/RoCE(尝试#2)

  • 建议添加 GigEVision 标准
  • *完全专有*直到批准(可能在 2 年内)
  • OTS NIC 支持的基于 RDMA 的协议
  • 开销使性能低于 UDP
  • 零拷贝技术
  • 使用重新发送/流量控制作为拐杖
  • 不是流媒体协议(如 USB/CXP)
  • 严格点对点(如 USB/CXP)
  • 不支持多播(如 USB/CXP)
  • Windows 不支持 NVIDIA GPUDirect

RDMA 相机:具有更多开销的零复制传输

与 UDP 一样,一些供应商正在寻求 RDMA 来避免标头拆分实现。 这些供应商在系统中使用超过 2 个 10GigE 摄像头时遇到问题,坦率地说,在基于 1GigE 的多摄像头系统上遇到问题。

RDMA 实现了到图像缓冲区的 0 拷贝传输——很好。 与 TCP 一样,RDMA 是一种连接技术,因此会产生开销并会限制可扩展性。 除非系统设计良好且裕量充足,否则永远无法保证性能。

RDMA 提供重新发送和流量控制以实现更可靠的传输,但这与 TCP 一样会影响性能并引起延迟和抖动。

与 TCP 一样,RDMA 也无法支持多播等基本网络技术。

RDMA 基本上是零拷贝 TCP 甚至是 USB。

RDMA 和 TCP 都是点对点技术,因此人们可能会问为什么使用 GigEVision 而不是 CXP 或 USB,特别是考虑到用于 CXP 图像采集卡和 Emergent 自己的卡的 fpgas 的成本/性能比大大提高。 我提醒一下,对于用于 RDMA 的相同 NIC,我们还可以利用卡的标头拆分功能来保持 GigEVision 标准完整,以实现无限集成。

另一个重要的现实是,TCP 和 RDMA 的流量控制和重新发送与相机中的缓冲一起使用。 无论它在哪里——无论是在相机中还是在卡中——缓冲都是可靠传输的基本要求。 此外,在任何设计中,无论是使用 UDP、TCP、RDMA 还是 CXP,如果这些保护缓冲区溢出,您就会丢失数据。

一旦数据进入系统内存,您将如何处理这些数据?

图:GigE Vision + RDMA/RoCE 实施向前迈进 1 步。

组播

  • 互联技术不支持广播/多播应用程序
  • 消除高效冗余
  • 消除分布式处理
  • 消除了网络的主要基础
  • 现在有空!

这张幻灯片突出了关于多播技术的要点。 GigEVision+GVSP是目前唯一支持的协议 这个基本的网络功能。 其他标准将很快 在需要高效冗余的应用程序中被驳回,并且 分布式处理。

互联技术不支持广播/多播应用程序

图:只有 GigEVision + GVSP 支持广播和多播。

接口的融合

这张幻灯片说明了提议或批准的更改如何融合接口标准。 USB 基本保持不变,但它是一种点对点技术。 CXP采用了向GigEVision汇聚的以太网物理层。 GigEVision+RDMA 和 GigEVision+TCP(如果批准)作为点对点技术融合到 CXP 和 USB。 (也许 2 年后)。 GigEVision+GVSP 将保持其完整性和功能集,不会与其他协议融合。

这张幻灯片说明了提议或批准的更改如何融合接口标准。

图:只有 GigEVision + GVSP 作为真正的流媒体协议脱颖而出。

加工技术

  • GPU 卡——所有处理都在卡上完成
  • FPGA 卡——所有处理都在卡上完成
  • GPUDirect – 绕过系统内存到 GPU
  • 点对点传输——将数据节点移动到节点
  • 人工智能引擎——GPU 和 FPGA 卡的特性
  • NIC 市场与 HPC 融合

因此,假设我们现在通过任何方式将数据安全地保存在系统内存中。 现在我们用它做什么? 我们在上面谈到了这个想法,它似乎甚至不是那些致力于修改 GigE Vision 标准以添加 RDMA 或 TCP 的讨论的一部分。 对于一些 高速视觉应用s,CPU和系统内存是足够的资源。 对于使用多个其他性能应用程序 100GigE, 25GigE 甚至 10GigE 相机,实时处理需要将任务卸载到更适合的处理节点。 CPU 及其系统内存通常无法应对。 RDMA 和 TCP 现在重要吗? 答案是否定的,因为这些卡同样可以处理 GVSP。 让我们看一些例子来理解为什么。

CPU 及其系统内存对高速应用程序的作用有限。

图:现成的 NIC 无法处理像素数据,只能将像素数据传递给系统。

GPU直连

  • 0 CPU 和 0 系统内存带宽
  • NVIDIA 产品需要适用于 Windows 的 Rivermax
  • NVIDIA 需要合作伙伴——选择几个
  • Linux 对标准 GPU 上的 GPUDirect 开放
  • 80% MV 在 Windows 上的应用
  • 一些应用程序包括 AOI、无人机、VR、运动
  • 降低 PC 要求
  • 点对点支持
  • 现在有空!

GPUDirect 是一项了不起的技术,我们的许多客户都在使用它 在 AOI、无人机、VR 和体育应用中,仅举几例。 在这种情况下,CPU 和系统内存保持不变 而数据则直接从 NIC 传输到 GPU。 在 Linux 上,许多具有任意 NIC 的 GPU 都可以实现类似的许多事情。 Windows 上的 NVidia GPU 仅允许来自使用 Rivermax 的 Mellanox NIC 的 GPUDirect 适用于 Emergent 等精选合作伙伴供应商。 此处 RDMA 不支持 GPUDirect。 80% 的机器视觉应用程序都在 Windows 上,它确实限制了 其他希望实现此功能的人。 乙mergent 已经支持此功能超过 2 年。

用于 GigE Vision 相机的 UDP、TCP 和 RDMA Emergent

图:GPUDirect 将像素数据绕过 CPU 和系统内存直接传递给 GPU。

视频:GPU Direct + HZ-65000G 100GigE 演示。

视频:NVidia Xavier + HZ-21000G 100GigE。

英伟达蓝田

  • 0 CPU 和 0 系统内存带宽
  • 需要单个 PCIe 插槽
  • CPU 完全不参与
  • NVidia 产品需要 Windows 上的 Rivermax
  • NVidia 需要合作伙伴
  • 80% MV 在 Windows 上的应用
  • 降低 PC 要求
  • 点对点支持
  • 未来的 HPC 集成模型即将到来
  • 现在有空!

与上一张幻灯片类似,NVidia 已将 NIC 与处理资源合并 启用单槽解决方案。 未来的模型有望成为 NVidia 专注于 HPC。 作为 NVidia 的合作伙伴,Emergent 可以使用所有这些技术。 这些技术也不限于单个视频流,而是可以处理 多个流仅受设备资源的限制。

用于 GigE Vision 的 UDP、TCP 和 RDMA

图:Nvidia Bluefield 技术为 NIC 提供内置处理资源。

带 GVSP 的 OTS FPGA 卡

  • 0 CPU 和 0 系统内存带宽
  • CPU 完全不参与
  • 具有原生 Emergent 的 OTS FPGA 卡提供 GVSP 内核支持或 Xilinx 等提供的 OTS GVSP 内核。
  • 丰富的MV算法
  • Windows 和 Linux 支持
  • 降低 PC 要求
  • 点对点支持
  • 现在有空!

在机器视觉领域,我们期待像 Matrox 和 Gidel 这样的公司提供带有 GigEVision+GVSP 前端的 FPGA 处理卡,以允许
与 Emergent 相机无缝集成。 GPU 作为处理节点占有一席之地,但 FPGA 卡通常可以更有效地处理工作负载。 客户可以利用供应商 IP 加快上市时间。 这些技术也不限于单个视频流,而是可以处理仅受设备资源限制的多个流。

GigE 视觉相机

图:带有 GigEVision+GVSP 前端的 FPGA 处理卡。

OTS FPGA卡

  • 0 CPU 和 0 系统内存带宽
  • CPU 完全不参与
  • 具有原生 Emergent 的 OTS FPGA 卡提供 GVSP 内核支持或 Xilinx 等提供的 OTS GVSP 内核。
  • 丰富的MV算法
  • Windows 和 Linux 支持
  • 降低 PC 要求
  • 点对点支持
  • 现在有空!

以太网的好处之一是我们可以从庞大的跨行业资源池中汲取灵感。 Xilinx 是我们密切合作的供应商之一,可提供先进的处理资源。 为了与 Emergent 相机集成,客户可以采用他们当前的 GigEVision 内核并将其移植到 Xilinx Alveo 等已经具有与我们的相机相同接口的卡中的一个。 对于 GigEVision 驱动程序的新手,我们可以为这些卡提供移植固件和驱动程序,让您快速启动和运行,让您专注于应用程序的细节。 通过快速搜索,您将意识到可供您使用的丰富的 FPGA 代码资源。 这些技术也不限于单个视频流,而是可以处理仅受设备资源限制的多个流。

用于 GigE Vision 的紧急 UDP、TCP 和 RDMA

图:Emergent 相机与 Xilinx Alveo 无缝集成。

应急卡

  • GVSP 支持
  • Windows 和 Linux 支持
  • 降低 PC 要求
  • GPUDirect支持
  • 点对点支持
  • 前端口触发器
  • 完整的供应链控制
  • 智能图像路由
  • 用于 MV 的智能 NIC 系列中的第一个
  • 现在有空!

Emergent 开始进军 PCIe 卡 为我们的客户提供某些好处的空间,例如智能图像重新排序、路由、
和扩展缓冲区。 此外,我们有一些客户希望避免在他们的设置中使用交换机,因为摄像机间隔很远并且距离适合光纤。 然而,他们仍然想要紧密同步。 我们带有用于图像触发的动作命令的前端口触发器满足了这一需求。 开发我们自己的卡还使我们能够管理我们典型客户应用的完整供应链,并保持严格的质量控制。 Emergent 还将着眼于开发先进的处理卡以满足我们客户的需求以及应用特定模块以缩短上市时间。 这些技术也不限于单个视频流,而是可以处理仅受设备资源限制的多个流。

网络接口卡

图:Emergent 自己的 PCIe 卡可以管理整个供应链以进行数据传输。

36摄像头系统

  • 最高性能的单 PC 解决方案
  • Windows 和 Linux 支持
  • 成本最低的多摄像头设置
  • 交钥匙 eCapture 软件支持
  • 使用 GPU 或 FPGA 处理节点进行自定义
  • 轻松扩展到多个服务器和处理节点
  • 0数据丢失
  • 现在有空!

我们在一些在线演示以及 NAB Vegas 等贸易展以及上个月在斯图加特的 Vision Show 上展示了这种设置。 该系统是迄今为止市场上性能最高、密度最高的解决方案。 该系统在接收 0 Gbps 图像数据并将其存储到 210 个 U.8 NVMe 驱动器时实现了 2 数据丢失。 该服务器是运行我们的 eCapture Pro 性能软件的单个中档 AMD 和华硕服务器配置。 一些客户希望采用此设置并在可用插槽中添加 GPU 以执行实时处理。

我们有一些客户使用我们的系统在单个系统中扩展了多达 250 多个摄像头的系统 25GigE 相机——这体现了可扩展性的易用性。

如前所述,我们有一些客户希望避免在他们的设置中进行切换。 通过我们的合作伙伴网络,对于 7,000 端口/48G+25 端口/8G 配置,交换机的起价约为 100 美元,但有助于大幅降低整体系统成本。 也可提供更小的配置,如 18 端口/25G+4 端口/100G。 随着越来越多的公司进入市场并支持 25G/100G 和 PTP,交换机市场的竞争也越来越激烈。 您可以依靠 Emergent 获得开关电源和配置方面的支持。

36x 10GigE 相机

图:36 x 10GigE 相机系统的剖析。

视频:36 x 10GigE 相机系统演示。

eCapture Pro

eCapture Pro 建立在 Emergent 的 eSDK 之上,是使我们能够在市场上实现最高性能的粘合剂。 正在为自定义性能可部署系统添加和支持处理节点技术。

现在有空!

eCapture PRO 现已上市!

图:eCapture Pro,Emergent 的全功能应用软件。

Q / A

Emergent会采用GigEVision+TCP还是GigEVision+RDMA?

目前,只有少数小公司积极参与这项工作 标准,而市场上最大的参与者却在观望。 有些人实际上试图在早期阶段将其用作营销噪音 陈述一些优于现有解决方案的优势。 预计行业采用将非常缓慢,因为内部的大多数事情 机器视觉市场。 完全批准的标准可能需要 2 年时间 所以我们当然有时间适应,对于 Emergent 这会很快 如果需要,通过固件升级到我们现有的任何完全认证的产品。 事实上,一般的头部拆分是最高性能和最灵活的 卸载的方法。 灵活性的一个例子是可以使用相同的方法 对于 SMPTE 2110 协议——使用 RDMA 和 TCP 的 GigEVision 实现是 把自己逼到墙角。 我们不会做的一件事是同时推广和销售使用 RDMA 或 TCP 的相机 GigEVision 标识,直到添加内容获得批准,因为这可能会产生误导。

客户关心使用的是 GigEVision+TCP、GigEVision+RDMA 还是 GigEVision+GVSP?

目前,没有 Emergent 客户对 TCP 或 RDMA 感兴趣。

以下是您的高速应用需要考虑的事项:

  • 承诺– 供应商是否致力于高速发展,或者供应商是否由于缺乏重点而分散得太少?
  • 表现——我性能是通过什么方式实现的?
  • 灵活性– 供应商是否接受定制选项?
  • 支持 - 您的支持请求的周转速度有多快? 供应商在应用程序的各个级别从头到尾与您同在?
  • 价格 - SYSTEM LEVEL 的性价比是否可以接受? 您必须比较完整解决方案的定价。
  • 供应链 - 我现在和几年后多久可以拿到我的产品?
  • 经验– 这个产品有多成熟 不要太相信一个供应商的说法? 经验和尽职调查一样重要。

考虑所有这些要点并做出决定。

是什么导致标准趋同?

融合发生在标准化程度不高的行业。 它可以突出标准的问题。 例如,CXP 就没有足够的前瞻性,并意识到使用同轴电缆实际上无法实现高速和更长的电缆长度——因此 CXP 采用了以太网物理层。 其他时候,比如 GigEVision+GVSP,问题不在于标准,而在于实施,因此有些人有时会非常匆忙地改变标准,有时会达到营销“我第一”的状态。

GigEVision+RDMA 与 GigEVision+GVSP 相比,缓冲区溢出的可能性更大吗?

如前所述,GigEVision+RDMA 的开销将高于 GigEVision+GVSP,这会导致 GigEVision+RDMA 系统上的缓冲区溢出更快。 应该注意的是,使用此缓冲区越少,系统将表现出的延迟和抖动就越低。 缓冲区越大,可靠性可能越高,但缓冲区中备份的图像越多,性能越低,延迟和抖动也越大。 因此,提醒您,在所有情况下,正确调整的服务器(包括 BIOS 更改与性能接收器驱动程序一致)对于限制缓冲区备份以最大限度地提高性能都很重要。

多播对客户有多重要?

多播中的两个主要考虑因素是分布式处理和系统冗余。 一些系统可以容忍停机时间,在这种情况下,系统冗余可以通过简单地手动更换有问题的组件或等待系统重新启动然后重新上线来处理。 多播允许最快的故障转移实现。

某些系统的处理要求较低,并且可以在单个 CPU 处理节点上处理该处理。 多播允许将相同的图像数据同时发送到多个处理节点以进行实时并行处理。

关于Emergent Vision Technologies

紧急标志

以下是对 Emergent 的概述……

  • 10 多项创新和开创高速 GigEVision 成像运动的奖项
  • 10 年以上销售 10GigE 超过 140 种型号的相机
  • 5 年以上销售 25GigE 超过 55 种型号的相机
  • 2 年以上销售 100GigE 超过 16 种型号的相机
  • 相机技术性能领先
  • 专注于高速以太网/GigEVision
  • 专注于实现高速图像数据的处理
  • 区域扫描线扫描 模型
  • 用于多光谱应用的 UV、NIR、偏振、彩色、单色模型
  • Emergent eSDK 实现全面的应用灵活性
  • 应急 eCapture Pro 高度综合的软件解决方案
  • 最全面的产品范围和对高速成像应用的支持
  • 任何速度、任何分辨率、任何电缆长度
  • 现在有空!

我们是一家屡获殊荣的公司,专注于高速 GigEVision 产品。

我们有多年的产品运输速度,从 10GigE 高达 100GigE.

我们非常注重为客户的应用程序提供端到端技术和支持。

我们可以满足大多数应用需求。

最后,展示的产品现已上市。

采用 10GigEVision 及更高版本

以下是采用 GigEVision 产品的快速快照,速度范围从 10GigE 高达 100GigE. Emergent 展示了如何实现顶级性能,并开辟了许多市场,包括使用此类技术的机器视觉。 一些公司刚刚开始利用我们的努力来发布 25G 和更高速度的产品,但距离发布经批准的高性能产品还有很长的路要走。

用于 GigE Vision 的 UDP、TCP 和 RDMA

图:Emergent Vision Technologies 是第一家基于 10GigE、25GigE、50GigE 和 100GigE 接口的相机供应商。