18

这是设置...您的系统正在接收包含离散消息的数据流（通常每条消息在 32-128 字节之间）。作为处理管道的一部分，每条消息都通过两个物理上独立的应用程序，它们使用低延迟方法（例如通过 UDP 的消息传递）或 RDMA 交换数据，最后通过相同的机制到达客户端。

假设您可以在任何级别注入自己，包括有线协议分析，您将使用哪些工具和/或技术来测量系统的延迟。作为其中的一部分，我假设传递到系统的每条消息都会导致相应的（尽管不等效）消息通过系统推送并传递给客户端。

我在市场上见过的唯一这样的工具是 TS-Associates TipOff。我敢肯定，通过正确的访问，您可能可以使用电线分析工具（ala wireshark）和正确的解剖器测量相同的信息，但这是正确的方法还是我可以使用任何商品解决方案？

4

4 回答 4

9

您的最后一段是需要完成的典型方式。该领域的常见嫌疑人（至少据我所知的市场数据（华尔街）延迟）是：

  • TSA（TS 协会）
  • Correlix
  • 科维尔
  • Napatech（硬件捕获设备）
  • Endace（硬件捕获设备）

还有一家经营不善的公司最近烧光了他们的风险投资资金（400 万？）。

对于被处理成不同格式的数据（比如说在直接交换提要或 RMDS 或其他更改协议的服务器），您需要能够解析有效负载以关联消息。这可能具有挑战性，因为有时数据供应商不会公开消息定义。

我认为有些硬件设备会在其中注入带有时间戳的有效负载信息，以便客户端可以看到这些信息。当然，正如另一位发帖人指出的那样——时间问题非常重要。所有设备和客户端都必须具有相同的时间参考点。一定要准确...

上次我与 TSA 交谈时，一个带有 4 个观察点的装置大约需要 15 万美元。我怀疑上面列出的其他价格相似。

上面列出的硬件卡起价约为 2000 美元（对于一张基本卡），然后（显着）上涨。

要在软件中执行此操作，您需要让客户端使用 pcap（或类似的东西）并查看有效负载并尝试匹配它们。在某些情况下，很难让它具有确定性——尤其是在“会话”开始时，或者如果一个管道中缺少消息。通常在某个阈值之后，如果你不匹配某些东西，你就放弃它。

编辑：免责声明：我现在也是合资企业的一部分，应该披露这一点。

于 2009-08-05T21:59:04.957 回答
4

最近的一篇论文可能有一些用处（并且也比基于硬件的解决方案便宜得多）。还有一些方法可以相当准确地解释时钟偏差；上一次我认真研究单向延迟测量研究时（几年前），最准确的技术是 Sue Moon 的线性规划算法（参考代码可在此处方便地获得)，但是如果不使用一些相当现代的线性编程技术，作为在线算法来做是相当不切实际的；最好只记录时间戳，而不是全天定期进行任何计算，然后对累积的数据运行 LP 算法。还有一些其他技术足够快，可以在线完成（包括 Vern Paxson 的开创性论文），但它们都不太准确。

于 2009-11-18T07:18:10.390 回答
1

如果每条消息多几个字节对您来说不会是过大的杀伤力，我建议只在源处使用完整时间戳（64 位）标记消息，并在每个跃点上添加进入/离开时间戳增量（每个标记一个字节）。通过分析双向流，您将找出盒子之间的时钟偏差，然后您将能够获得完整的实时延迟信息供您考虑或发布到监控工具。

于 2010-05-10T15:19:52.090 回答
0

这样做的问题与在太空中测量“速度”非常相似：您必须询问延迟与什么相关？如果您尝试在线测量它，您将错过交换中的任何额外延迟，或接收端的协议堆栈中的任何额外延迟。你不能真正端到端地测量它，因为计算机将有两个不同的时钟，几乎不可能在不引入小错误的情况下进行协调（并且它们彼此漂移！）

唯一真正有希望的方法是测量往返延迟，假设您有从一端返回的消息确认收到。UDP 在堆栈中没有 ACK，因此必须将它们编码到应用程序的某个地方。您所做的是使用诸如 x86 的高分辨率计时器之类的东西来测量从消息发送到其响应出现之间的时间。

于 2009-08-05T21:59:07.170 回答