如何衡量低延迟环境中的延迟?

时间:2009-08-05 21:28:02

标签: latency measurement

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

假设您可以在任何级别注入自己,包括线程协议分析,您将使用哪些工具和/或技术来衡量系统的延迟。作为其中的一部分,我假设传递给系统的每条消息都会导致相应的(虽然不是等效的)消息被推送到系统并传递给客户端。

我在市场上见过的唯一这样的工具是TS-Associates TipOff。我确信通过正确的访问,您可以使用线分析工具(ala wireshark)和正确的解剖器来测量相同的信息,但这是正确的方法还是我可以使用任何商品解决方案?

4 个答案:

答案 0 :(得分:9)

您的最后一段是需要完成的典型方式。这个领域的常见嫌疑人(至少就我所知的市场数据(华尔街)延迟而言)是:

  • TSA(TS Associates)
  • Correlix
  • Corvil
  • Napatech(硬件捕获设备)
  • Endace(硬件捕获设备)

还有另一家运营良好的公司最近通过他们的风险投资资金(400万?)烧毁了。

对于处理的数据(例如,在直接交换源或RMDS或其他更改协议的服务器上),您需要能够解析有效负载以关联消息。这可能具有挑战性,因为有时数据供应商不会公开消息定义。

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

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

上面列出的硬件卡起价大约2万美元(对于一张裸骨卡)并从那里上升(显着)。

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

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

答案 1 :(得分:4)

A recent paper可能有一些用处(而且比基于硬件的解决方案便宜得多)。还有一些方法可以相当准确地计算时钟偏差;上一次我认真研究单向延迟测量研究(几年前),最简单的准确技术是Sue Moon的linear programming algorithm(参考代码方便可用{{3但是,如果没有使用一些相当现代的线性编程技术,那么作为在线算法的做法是相当不切实际的;最好只记录时间戳,而不是在一天中定期进行任何计算,然后在累积的数据上运行LP算法。还有一些其他技术可以快速在线完成(包括Vern Paxson的here),但它们都不太准确。

答案 2 :(得分:1)

如果每个消息多几个字节对你来说不会有些过分,我建议只在源上用完整时间戳(64位)标记消息,并在每一跳添加条目/离开时间戳增量(每个标记一个字节) 。通过分析双向流,您将计算出框之间的时钟偏差,然后您将能够获得完整的实时延迟信息供您考虑或发布到监控工具。

答案 3 :(得分:0)

这样做的问题与测量太空中的“速度”大致相同:你必须要求延迟相对于什么?如果您尝试在线路上测量它,您将错过切换或接收端协议栈中的任何额外延迟。你不能真正地端到端地测量它,因为计算机将有两个不同的时钟,几乎不可能协调而不会引入小错误(并且它们彼此漂移!)

真正有希望的唯一方法是测量往返延迟,假设您从一端收到确认收到的消息。 UDP在堆栈中没有ACK,因此它们必须在某处编码到应用程序中。你所做的就是使用x86的high-resolution timer之类的东西来测量发送消息和出现响应之间的时间。