【问题标题】:Low latency/high performance network (ethernet) messaging低延迟/高性能网络(以太网)消息传递
【发布时间】:2012-02-02 04:21:27
【问题描述】:

背景

我想创建一个测试应用程序来测试不同系统的网络性能。为此,我计划让该机器通过专用(否则不忙)网络将以太网帧发送到另一台机器(或设备),该机器(或设备)只是接收消息并将其发回。发送应用程序将记录总往返时间(除其他外)。

测试的目的是查看特定系统(操作系统 + 组件等)在网络流量方面的表现。这在下图中显示为机器 A。请注意,我对网络基础设施(交换机、电缆等)的性能不感兴趣 - 我正在尝试测试机器 A 内网络流量的性能(即从它碰到网卡直到它到达用户空间)

我们将(尝试)测量所有类型的东西,一是消息的总往返,还有机器 A 的中断延迟、一般驱动程序开销等。机器 A 将是一个实时系统。但是为了支持这些测试,我需要一台可以反弹消息并以其他方式向测试系统添加网络刺激的单独机器。这台单独的机器是下图中的机器 B,这就是这个问题的内容。

我的问题

我想开发一个能够以尽可能一致(最好是低)延迟接收和返回这些消息的应用程序。我希望至少在几微秒内获得一致的延迟。为简单起见,我想在 Windows 或 Linux 等通用操作系统上执行此操作,但我愿意接受其他建议。除了操作系统和我的测试应用程序之外,机器上不会有其他负载(CPU 或其他负载)。

我想到了以下方法:

  • 在用户空间中以高优先级运行的普通应用程序
  • 在内核空间中运行的线程以避免用户空间/内核空间转换
  • 现成的设备已经可以做到这一点(虽然我还没有找到)

问题

是否有其他方法或框架已经可以做到这一点?为了获得一致的低延迟,我还需要考虑什么?推荐什么方法?

【问题讨论】:

  • 问:“我还需要考虑什么才能获得一致的低延迟?” A:内核执行(linux)/驱动程序执行(windows)。也就是说,您能否阐明您关心的延迟限制以及您将如何使用您获得的信息? “尽可能精确”并不总是可行的,您可能会发现让您的测量结果“足够好”更容易
  • 要达到尽可能低的延迟,请考虑在 FPGA 中实现。您不需要处理器,只需要一个 MAC 和一些逻辑来在重新发送之前重写数据包标头。您可以开始使用带有 FPGA 和 PHY 的评估板。
  • @Mike:好点子。老实说,我不确定我可以期待什么数字,我准备好使用解决方案/系统可以给我的东西。虽然如果延迟在几微秒内保持一致会很好。我不知道这是否可能,因为我以前从未这样做过 - 事实上,作为问题的答案,这种输入将非常有价值
  • @IsakSavo,您能否说明您将如何使用您获得的信息?已经有嵌入式系统可以在微秒内测量和存档网络延迟;但是,我需要了解您的申请才能提供帮助

标签: windows linux performance network-programming


【解决方案1】:

您提到要测试机器A的内部性能,但“需要一台单独的机器”;但是,您不想测试网络基础架构的性能。

你比我更了解你的需求;但是,如果我在机器 A 中测试网络基础设施,我会这样设置我的测试:

这有几个原因:

  • 您可以使用以太网环回电缆来模拟机器 B 执行的“pong”功能
  • 在衡量性能时,消除通过您不关心的基础设施的传输几乎总是一个更好的解决方案

如果你使用这种测试方法,一定要注意以下几点:

  • 以太网在建立链路之前对铜线执行信噪比测试。如果您使环回弯曲过紧,则如果以太网由于电缆中的扭结而决定回退到较低的速度,则可能会引入更多延迟。铜质以太网电缆没有最小长度。
  • 您可能已经知道,网卡/驱动程序版本/操作系统的组合会对主机内延迟产生重大影响。我在一家网络设备制造商工作,办公室里的一个人曾经在SolarFlare 担任应用工程师。他声称许多华尔街交易系统都使用 SolarFlare 的 NIC,因为 SolarFlare 为其产品设计了低延迟;他还说 SolarFlare 的驱动程序让您可以在用户空间访问 NIC 缓冲区。警告:第三方信息,我无法验证自己。
  • 如果将帧循环到机器 A,请将源和目标 mac-address 设置为 NIC 上的烧录地址

即使您需要从机器 B 接收修改后的“pong”帧,您仍然可以使用此拓扑结构并简单地在机器 A 中代码的接收端重写数据包字段。放置尽可能多(或很少)的插桩在机器 A 的“模块”中随意点以比较帧时间戳。

仅供参考:

我在 cmets 关于您的问题中提到的嵌入式系统用于测量网络基础设施的延迟,而不是终端主机。这是我能想到的用于检测主机延迟的最佳方法。

【讨论】:

  • +1。优秀的答案。这正是我一直在寻找的那种见解。我一定会考虑这种方法
【解决方案2】:

作为现成的解决方案,我建议看看 Solace、Tibco 和 AMQP。这些都是在交易应用程序中广泛使用的企业消息传递框架。 AMQP 是开源的,能够处理高达每秒 100,000 条消息的吞吐量。我不确定其他框架的延迟。 AMQP 消息路由器有 Java 或 C++ 实现。 C++ 之一当然会返回更高的性能。

编辑我刚刚听说了一个名为UltraMessaging 的新产品,它可以通过Java、C++ 或C# 客户端提供每秒7,000,000 条消息的吞吐量。克里基。

最好的问候,

【讨论】:

  • 不错。这对于对系统进行压力测试可能很有用!谢谢
  • 当然可以。 700 万条消息是疯狂的吞吐量!
  • 很好的答案,但我想补充一点,超消息只能通过共享内存执行亚纳米延迟。此外,如果没有实现“x”的系统的相关信息/统计数据,则每个“y”数字的“x”可能会产生误导。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2013-07-01
  • 2012-01-03
  • 1970-01-01
  • 1970-01-01
  • 2023-03-29
  • 2022-12-14
相关资源
最近更新 更多