这里是设置...您的系统正在接收包含离散消息的数据流（通常在每个消息32-128字节之间）。作为处理管道的一部分，每条消息都通过两个物理上分离的应用程序，这些应用程序使用低延迟方法（例如UDP上的消息传递）或RDMA交换数据，最后通过相同的机制交付给客户端。如何测量低延迟环境中的延迟？
假设您可以在任何级别注入自己，包括有线协议分析，您将使用什么工具和/或技术来测量系统的延迟。作为其中的一部分，我假定传递给系统的每条消息都会导致相应（但不等同）的消息被推送通过系统并传递给客户端。
我在市场上看到的唯一工具是TS-Associates TipOff。我确信，通过正确的访问方式，您可以使用电线分析工具（ala wireshark）和正确的解析器来测量相同的信息，但这是正确的方法，还是我可以使用任何商品解决方案？
您的最后一段是它需要完成的典型方式。在这一领域通常的嫌疑人（至少据我知道的市场数据（华尔街）延迟）是：
又是经营不善的公司，最近通过他们VC的钱（4元烧？）。
对于被处理（让我们以直接交换饲料或RMDS或其他服务器更改协议说吧）到你需要能够解析有效载荷的关联消息不同格式的数据。由于有时数据供应商不公开消息定义，因此这可能很具挑战性。
我认为有硬件设备将注入有效载荷信息与时间戳，因此客户端可以看到这些。当然，正如另一张海报所指出的 - 时间问题非常重要。所有的设备和客户必须有相同的时间参考点。它必须是准确的...
我最后一次与TSA交谈时，有4个观察点的装置价值约为150k美元。我怀疑上面列出的其他人的价格是相似的。
上面列出的硬件卡的价格大约是2k美元（对于裸机卡）并从那里上涨（显着）。
要在软件中做到这一点，你需要客户使用PCAP（或类似的东西），看看有效载荷，并尝试匹配它们。在某些情况下，很难确定这一点 - 尤其是在“会话”开始时或者某个管道中缺少消息。通常在某个门槛之后，如果你不匹配某个东西，你就放弃它。
编辑： 免责声明： 我现在也是风险投资的一部分，应该披露这一点。
++ TipOff在调整到具体细节后运行良好。您可以使用原始捕获功能自行完成，但它们的硬件使得数据更容易获取并有效地为其添加时间戳。一旦你完成了初始阶段的工作，它会自动完成。 – ShuggyCoUk 2009-08-05 22:10:25
这样做的问题与在空间测量“速度”非常相似：您必须提出相对于什么的延迟？如果你尝试在线路上测量它，你会错过任何额外的交换延迟，或在接收端的协议栈。你真的不能衡量它最终到终端，如电脑将有两个不同的时钟，它几乎是不可能调和W/O引入小错误（和它们相互漂移！）
的唯一方法真正有希望的是衡量往返延迟，假设你有从一端确认收到的消息。 UDP在堆栈中没有ACK，因此必须将它们编码到某处的应用程序中。你所做的就是使用类似于x86的high-resolution timer的东西来衡量消息发送和响应出现之间的时间。
A recent paper可能有一定的用途（并且也会比基于硬件的解决方案便宜很多）。也有相当准确地计算时钟偏斜的方法;我最后一次认真研究单向等待时间测量研究（几年前），最精确的技术是Sue Moon的linear programming algorithm（参考代码方便可用here），但是没有使用一些相当现代的线性编程技术，作为一种在线算法是不切实际的;最好只记录时间戳，而不需要在整个一天中定期进行任何计算，然后在累积的数据之后运行LP算法。还有一些其他技术可以在线快速完成（包括Vern Paxson的seminal paper），但它们都不太准确。
如果每条消息还有几个字节对你来说不会是一种过度消耗，我建议在源文件中用完整的时间戳（64位）加上消息并在每一跳上添加进入/离开时间戳增量（每个戳一个字节）。通过分析双向流程，您可以计算出各个盒子之间的时钟偏差，然后您就可以获得完整的实时延迟信息，供您考虑或发布到监测工具。
没有真正的编程相关，也许更好的serverfault，但仍然非常有趣。 – Cheeso 2009-08-05 21:31:25