使用系统时钟测量广播消息延迟，好主意吗？
我想测量 1GB LAN 上消息代理的广播消息延迟。
消息以 pub sub 方式传输，一个发布者，多个消费者。生产者使用系统时钟（C# 中的 DateTime.Now）为每条消息添加时间戳，而消费者通过从 DateTime.Now 中减去消息上的时间戳来测量延迟。
double latency = (DateTime.Now - msg.NMSTimestamp).TotalMilliseconds;
我们 LAN 上的所有设备每小时通过 NTP 同步一次时间，但我发现明显的延迟，甚至负时间在 +/- 1 秒的范围内。我读到 NTP 应在 LAN 环境中提供约 5 毫秒的精度。
我的测量策略是否存在根本缺陷？对于负延迟还有其他解释吗？如果我只看到较大的延迟，我会怀疑我们的消息队列很慢，但负面的延迟确实让我感到困惑。
I want to measure broadcast message latency over our message broker on a 1GB LAN.
Messages are transmitted in a pub sub fashion, one publisher, many consumers. The producer timestamps each message using the system clock (DateTime.Now in C#) and consumers measure latency by subtracting the timestamp on the message from DateTime.Now.
double latency = (DateTime.Now - msg.NMSTimestamp).TotalMilliseconds;
All of the boxes on our LAN sync their time via NTP once an hour yet I'm seeing significant latency and even negative times in the range of +/- 1 second. I read that NTP should provide ~5ms accuracy in a LAN environment.
Is my measurement strategy fundamentally flawed? Is there another explanation for the negative latency? If I was only seeing large latencies I'd suspect our message queue was slow but the negative ones really have me confused.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您的负值以毫秒为单位是多少？如您所知，如果在 5 毫秒之内，这对于 NTP 来说是正常的。如果一台计算机比真实时间提前 5 毫秒而另一台计算机落后 5 毫秒，则计算机之间的差异甚至可能高达 10 毫秒。更重要的是，我猜测系统中的某个地方存在一些舍入错误、先行/后行错误或同步错误。有许多硬件和实现细节您几乎无法控制，从而可能会产生不准确的结果。一般来说，当 DateTime.Now 轮询时，系统时钟在毫秒级别上足够准确，但许多硬件细节（例如负载下的 CPU 节流、管道、缓存抖动等）可能会引入足够的错误，在毫秒级别上非常严重。
如果可能，请将计算机设置为与 NTP 服务器同步，彼此之间至少间隔一秒。如果所有计算机尝试每小时按整点同步，则 NTP 服务器将被淹没，从而由于拥挤和数据包调度而增加报告正确时间的不准确性。我认为这是发生这种情况最有可能的原因。此外，通过减少电缆敷设（理论上最大长度为 300 英尺，在 EMI 噪声环境中，敷设短至 40 英尺可能会导致严重问题）、用交换机替换集线器以及尽量减少无线网络，确保您的网络尽可能高效。网络使用。
What are your negative values looking like in millis? If it's within 5ms, that's normal for NTP, as you know. There could even be up to 10 millis difference between computers if one computer was 5 millis ahead of true time and another was 5 behind. More than that, I would guess that there's some rounding error, lookahead/lookbehind error, or sync errors somewhere in your system. There are many hardware and implementation details you have little control over that can produce inaccuracies. GENERALLY, system clocks are accurate enough at the millisecond level when polled by DateTime.Now, but many hardware details like CPU throttling under load, pipelines, cache thrashing etc. can introduce enough error to be significant at the millisecond level.
If possible, set up your computers to synchronize with the NTP server at least a second apart form each other. If all computers try to sync on the hour every hour, the NTP server will be flooded, increasing inaccuracies in reporting the correct time due to crowding and packet scheduling. I think this is the most likely cause for what's going on. Also, make sure your network is as efficient as possible, by reducing cable runs (300ft is the theoretical maximum, and in an EMI-noisy environment runs as short as 40 feet can cause serious problems), replacing hubs with switches, and minimizing wireless network use.
我记录了一些由同一时钟测量的负网络延迟事件。
Windows 无法实现时钟偏差，因此每当发生同步时您都会看到这些偏差。
Windows 不保证 5ms 精度，但仅保证每秒 18.2 个刻度。我的机器提供 15ms 的 epsilon。
I have a handful of incidents logged of negative network latency measured by the same clock.
Windows fails to implement clock skew, so you see these whenever a sync happens.
Windows does not guarantee 5ms accuracy, but only 18.2 ticks per second. My machine provides an epsilon of 15ms.