想象一下，在异构网络环境中，许多主机上有许多群集服务器，这样服务器之间的连接可能会有很大的延迟和带宽。您希望通过在服务器之间传输数据来构建服务器之间连接的映射。
当然，随着网络拓扑的变化，这张地图可能会随着时间的推移而变得陈旧 - 但是现在让我们忽略这些复杂性并假设网络是相对静态的。
鉴于此主机图中节点之间的延迟，计算带宽是一个相对简单的计时练习。然而，我在延迟方面遇到了更多困难。要获得往返时间，只需计时从本地主机到远程主机的返回ping时间 - 本地主机上都会发生定时事件（启动，停止）。
假设延迟在两个方向上不相等，我想要单向时间怎么办？假设各个主机上的时钟没有精确同步（至少它们的误差与所涉及的延迟具有相同的幅度） - 我如何计算单向延迟？
在一个相关的问题中 - 在实践中常见的是这种非对称延迟（其中链接方向比另一方更快）吗？出于什么原因/硬件配置？当然我知道非对称带宽场景，特别是在最后一英里的消费者链接上，比如DSL和Cable，但我不太确定延迟。
已添加：在考虑下面的评论后，问题的第二部分可能会更好地放在serverfault上。
答案 0 :(得分：8)
据我所知，非对称延迟 - 尤其是“最后一英里”不对称 - 无法自动确定，因为任何网络时间同步协议同样受到相同的不对称性影响，因此您没有从中评估不对称性的参考。
如果每个端点都有自己的GPS时钟，那么你就有一个可以使用的参考点。
在 Fast Measurement of LogP Parameters for Message Passing Platforms 中，作者指出延迟测量需要在被测系统外部进行时钟同步。 （粗体强调我的，原文中的斜体。）
非对称延迟只能通过发送带有时间戳 t s 的消息来测量，并让接收器从 t r <导出延迟/ sub> - t s ，其中 t r 是接收时间。 需要发送方和接收方之间的时钟同步。如果没有外部时钟同步（如使用GPS接收器或专用软件，如网络时间协议，NTP），时钟只能同步到往返的粒度两个主机之间的时间 [10]，这对测量网络延迟毫无用处。
但是，基于网络的算法（例如NTP）不会消除最后一英里链接问题，因为算法的每个输入本身都会受到最后一英里链接的性能特征的影响，因此不是“外部” “在上面给出的意义上。 （我相信它可以构建一个证明，但我现在没有时间构建证明。）
答案 1 :(得分：3)
有一个名为One-Way Ping（OWAMP）的项目专门用于解决此问题。可以在LKML中看到活动，以便为传入的数据包（SO_TIMESTAMP，SO_TIMESTAMPNS等）添加高分辨率时间戳，以帮助计算此统计信息。
http://www.internet2.edu/performance/owamp/
甚至还有Java版本：
请注意，数据包时间戳确实需要硬件支持，而且许多现有的生成NIC仅提供毫秒级的分辨率，这可能与主机时钟不同步。 DDK中有关于同步主机和数据的MSDN文章。 NIC时钟显示潜在问题。由于核心差异，TSC的以纳秒为单位的时间戳存在问题，并且可能需要Nehalem架构以所需的分辨率正常工作。
http://msdn.microsoft.com/en-us/library/ff552492(v=VS.85).aspx
答案 2 :(得分：0)
您可以通过向返回固定大小数据包的端口发送不同大小的数据包来测量链路上的非对称延迟，例如将一些udp数据包发送到回复icmp错误消息的端口。 icmp错误消息总是大小相同，但您可以调整正在发送的udp数据包的大小。
答案 3 :(得分：0)
sping tool 是该领域的一项新发展，它使用与附近 NTP 服务器的时钟同步，或更准确的 GNSS 盒形式的源来估计非对称延迟。
更详细地介绍了该方法in this blog post。
答案 4 :(得分：-1)
在没有同步时钟的情况下，无法像2011年论文"Fundamental limits on synchronizing clocks over networks".中证明的那样测量不对称性