【问题标题】:Is it possible to stream data into a ZeroMQ message as it is being sent via UDP?是否可以在通过 UDP 发送数据时将数据流式传输到 ZeroMQ 消息中?
【发布时间】:2016-02-09 07:03:46
【问题描述】:

我们正在通过 30fps 处理延迟关键型应用程序,该应用程序包含多个阶段(例如压缩、网络发送、图像处理、3D 计算、纹理共享等)。

通常我们可以像这样实现这些多个阶段:

[Process 1][Process 2][Process 3]

---------------time------------->

但是,如果我们可以堆叠这些进程,那么[Process 1] 可能会在处理数据时不断将其结果传递给[Process 2]。这类似于iostream 在 c++ 中的工作方式,即“流式传输”。使用线程,这可以减少延迟:

[Process 1]
    [Process 2]
        [Process 3]
<------time------->

假设[Process 2] 是我们的UDP 通信(即[Process 1] 在计算机A 上,[Process 3] 在计算机B 上)。

[Process 1] 的输出大约是 3 MB(即通常 > 300 个巨型数据包,每个 9 KB),因此我们可以假设当我们调用 ZeroMQ强>的:

socket->send(message); // message size is 3 MB

然后在库或操作系统的某个地方,数据被分成按顺序发送的数据包。该函数假定消息已经完全形成。

在通过UDP 发送大数据时,是否有办法(例如 API)使部分消息“正在构建”或“按需构建”?这在接收方是否也是可能的(即允许在消息的开头采取行动,因为消息的其余部分仍在传入)。或者..是我们自己手动将数据分成更小的块的唯一方法吗?

Note:
网络连接是计算机 A 和 B 之间的直线 GigE 连接。

【问题讨论】:

标签: c++ zeromq iostream low-latency


【解决方案1】:

不,你不能真正做到这一点。 API 没有提供,ZeroMQ 承诺接收者将获得完整的消息(包括多部分消息)或根本没有消息,这意味着在消息完全传输之前它不会向接收者呈现消息.将数据自己拆分为单独的可操作块,作为单独的 ZeroMQ 消息发送是正确的做法。

【讨论】:

    【解决方案2】:

    TLDR; - 简单的答案是否定的,ZeroMQ SLOC 不会帮助您的项目获胜。该项目是可行的,但需要另一个设计视图。

    已经陈述了最少的事实:
    - 30fps
    - 3MB/frame
    - 3 阶段处理管道,
    - 私有主机-主机 GigE-interconnect,

    没有更多细节,没有什么可以决定的。

    当然,管道端到端处理的阈值约为 33.333 [ms](而您计划直接失去一些 30 [ms] strong>networkIO ),剩下的就交给设计师了。哎哟!

    延迟控制设计不应跳过实时I/O设计阶段

    ZeroMQ 是一匹强者,但这并不意味着它可以挽救糟糕的设计。

    如果您在时间限制上花费一些时间,那么 LAN networkIO 延迟是您认为最大的敌人。

    参考: Latency numbers everyone should know

    1 ) DESIGN 处理阶段
    2 ) BENCHMARK 每个阶段的实现模型
    3 ) PARALLELISE 无论Amdahl's Law says这是有意义的,并且在可能的情况下

    如果您的代码允许并行处理,您的计划将更好地使用“渐进式”管道处理,并使用 ZeroMQ Zero-复制/(几乎)-延迟/-阻塞可在 inproc: 传输类中实现,并且您的代码可能支持“渐进式”流水线当您在多个处理阶段中进行时。

    请记住,这不是单行的,不要指望 SLOC 来控制您的“渐进式”流水线制造。

    [ns] 问题,请仔细阅读您从数据处理微基准测试中获得的数据。
    它们确实决定了您的成功。
    在这里,您可能会看到在更改颜色表示时“损失”/“浪费”了多少时间,您的代码在对象检测和 3D 场景处理和纹理后处理中需要这些时间。因此,请将您的设计标准设置为相当高的标准水平。

    检查左下窗口numbers,该实时管道大约损失了毫秒数。

    如果使用{ quad | hexa | octa }-core CPU 资源,您的代码处理要求不能安全地满足您的 33,000,000 [ns] 时间预算,并且如果数值处理可能受益于many-core GPU 资源,则可能有在这种情况下,Amdahl's Law may well justify 用于一些异步多 GPU 内核处理方法,其额外的 +21,000 ~ 23,000 [ns] 在初始/终端数据传输中丢失 +350 ~ 700 [ns]GPU.gloMEM -&gt; GPU.SM.REG 延迟屏蔽(在图像处理的情况下,它很高兴具有足够的准并行线程深度,即使对于预期的普通 GPU 的低计算密度也是如此 -内核)
    Ref.:
    GPU/CPU latencies one shall validate initial design against:

    【讨论】:

    • 感谢您的深入解释!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-03-10
    • 2017-12-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-09-21
    相关资源
    最近更新 更多