低延迟/高性能网络(以太网)消息传递

Question

背景

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

测试的目的是查看特定系统（操作系统 + 组件等）在网络流量方面的表现。这在下图中表示为机器A。请注意，我不关心网络基础设施（交换机、电缆等）的性能 - 我试图测试从网络卡到用户空间的网络流量的性能。

我们将（尝试）测量各种事物，其中之一是消息的总往返时间，还包括机器A的中断延迟、一般驱动程序开销等。机器A将是实时系统。但是为了支持这些测试，我需要一个可以反弹消息并以其他方式向被测试系统添加网络刺激的单独机器。下图中的这个单独的机器是机器B，这也是本问题的重点。

问题

我想开发一个应用程序，可以尽可能一致（最好是低）地延迟接收并返回这些消息。我希望获得的延迟在几微秒内保持一致。为简单起见，我想在像Windows或Linux这样的通用操作系统上进行测试，但我可以考虑其他建议。除了操作系统和我的测试应用程序之外，该机器上将没有其他负载（CPU或其他负载）。

我想到以下方法：

• 在用户空间运行的普通应用程序，具有高优先级
• 运行在内核空间的线程，以避免用户空间/内核空间转换
• 已经执行此操作的现成设备（尽管我尚未找到）

问题

是否有其他方法或框架已经实现了这一点？为了获得一致且低延迟的结果，我还需要考虑哪些方面？哪种方法是推荐的？

- Isak Savo

---

问：“我需要考虑什么才能获得一致且低延迟？” 答：内核执行（Linux）/驱动程序执行（Windows）。 话虽如此，您能否澄清您关心的延迟限制以及您将如何使用所获得的信息？ 并不总是实际可行的“尽可能精确”，您可能会发现对于您的测量来说“足够好”更容易。 - Mike Pennington

为了达到最低的延迟，考虑在FPGA中实现此功能。您不需要处理器，只需要一个MAC和一些逻辑来重新发送前重写数据包头部。有带有FPGA和PHY的评估板可供使用。 - Adrian Cox

@Mike：说得好。老实说，我不确定可以期望什么样的数字，但我准备根据解决方案/系统所能提供的来工作。如果延迟在几微秒内保持一致，那就太好了。我不知道这是否可能，因为我以前从未做过这样的事情——实际上，这种回答对于这个问题非常有价值。 - Isak Savo

@Seph：感谢你的建议。hrPing 在我们计划中的一些测试中可能会很有用。 - Isak Savo

@IsakSavo - 我刚听说了一个叫做UltraMessaging的新产品，它可以通过Java、C++或C#客户端提供每秒700万条消息吞吐量。哇塞。 - Dr. Andrew Burnett-Thompson

Answer 1

您提到您想测试Machine A的内部性能，但是“需要一台单独的机器”；然而，您不想测试网络基础设施的性能。

您对自己的要求了解得比我多得多；但是，如果我要在Machine A中测试网络基础设施，我会像这样设置我的测试：

（图片）

这样做有几个原因：

- 您可以使用以太网环回电缆来模拟Machine B执行的“pong”功能 - 在测量性能时，消除您不关心的基础设施的传输几乎总是更好的解决方案

如果您使用此测试方法，请确保注意以下几点：

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

即使您需要从Machine B接收修改后的“pong”帧，您仍然可以使用此拓扑结构，并在Machine A的代码接收端重写数据包字段。在Machine A的“模块”中放置尽可能多（或少）的检测点，以比较帧时间戳。

FYI：

我在对您的问题发表评论时提到的嵌入式系统是用于测量网络基础设施的延迟，而不是终端主机。这是我能想到的最好的方法来检测主机延迟。

- Mike Pennington

---

+1。非常好的回答。这正是我在寻找的见解。我一定会考虑这种方法。 - Isak Savo

Answer 2

作为一个现成的解决方案，我建议看一下Solace、Tibco和AMQP。这些都是在交易应用程序中广泛使用的企业消息框架。AMQP是开源的，能够处理高达100,000条每秒的吞吐量。我不确定其他框架的延迟情况。有一个AMQP消息路由器的Java或C++实现。当然，C++版本的性能更好。 编辑 我刚听说了一个叫做UltraMessaging的新产品，它可以提供每秒7,000,000条消息的吞吐量，支持Java、C++或C#客户端。哇塞！

此致敬礼

- Dr. Andrew Burnett-Thompson

---

不错。这可能对系统进行压力测试很有用！谢谢 - Isak Savo

当然可以。7m条消息是非常高的吞吐量！ - Dr. Andrew Burnett-Thompson

很好的回答，但我想补充一点，即超级消息传递只能通过共享内存实现亚纳秒的延迟。此外，“x”每“y”的数字如果没有关于实现“x”的系统的相关信息/统计数据，可能会误导人。 - JSON