使用系统时钟测量广播消息延迟，好主意？

Question

我想测量1GB LAN上的消息代理的广播消息延迟。

消息以pub sub方式传播，一个发布者，许多消费者。生产者使用系统时钟（C＃中的DateTime.Now）为每条消息加上时间戳，消费者通过从DateTime.Now中减去消息的时间戳来测量延迟。

 double latency = (DateTime.Now - msg.NMSTimestamp).TotalMilliseconds;

我们局域网上的所有方框每小时都会通过NTP同步一次，但我看到显着的延迟，甚至在+/- 1秒范围内的负时间。我读到NTP应该在LAN环境中提供~5ms的准确度。

我的测量策略是否存在根本缺陷？是否存在负延迟的另一种解释？如果我只看到大的延迟，我会怀疑我们的消息队列很慢，但是负面消息让我感到困惑。

Answer 1

你的负值是什么样的毫克？如果它在5ms内，那对NTP来说是正常的，如你所知。如果一台计算机比实际时间早5毫秒，另一台计算机落后5分，则计算机之间甚至可能存在高达10毫米的差异。更重要的是，我猜你的系统中有一些舍入错误，先行/后视错误或同步错误。有许多硬件和实现细节，你几乎无法控制，可能会产生不准确性。通常，在DateTime.Now轮询时，系统时钟在毫秒级别上足够准确，但是许多硬件细节如负载下的CPU限制，流水线，高速缓存抖动等都会在毫秒级别引入足够的错误。

如果可能，请将计算机设置为与NTP服务器同步，彼此至少间隔一秒。如果所有计算机每小时尝试同步一小时，则NTP服务器将被泛洪，由于拥挤和数据包调度而增加了报告正确时间的不准确性。我认为这是最可能的原因。此外，通过减少电缆运行（300英尺是理论上的最大值，并且在短距离40英尺的EMI噪声环境中可能导致严重问题）确保您的网络尽可能高效，用交换机替换集线器，并最大限度地减少无线网络使用。

Answer 2

我记录了由同一时钟测量的负网络延迟的少数事件。

Windows无法实现时钟偏差，因此无论何时发生同步，您都会看到这些。

Windows不保证5ms的准确率，但每秒只有18.2个滴答。我的机器提供15毫秒的epsilon。