有没有关于 NTP 准确性的研究资料？

Question 1

没有人能保证 NTP 在您的网络上的运行情况，因为没有人知道您的网络与互联网以及互联网上的时钟服务器的连接情况。但是，根据ntp.org 上的时钟规则算法页面

如果持续运行，家庭或办公室环境中快速 LAN 上的 NTP 客户端可以保持同步，名义上在 1 毫秒内。当环境温度变化小于 1 摄氏度时，即使时钟振荡器的固有频率偏移为 100 PPM 或更高，时钟振荡器频率也会被控制在百万分之一 (PPM) 以内。

请注意，LAN 和互联网时钟服务器之间较大但稳定的延迟对准确性的影响并不像高度可变的延迟那么严重。

您没有说您从哪里得到上述估计值（'50 微秒到......“低于一秒”'），所以我无法对它们发表评论，但根据我的经验，除非您有一个直接连接的时钟源，否则 50 微秒的可能性不大，除非您有一根湿绳将您连接到互联网并且您正在使用南极洲的上游服务器，否则 1 秒的可能性不大。

编辑：你现在在问题中引用的文本指向一篇论文，该论文在 1999 年确实证实了 99% 的 ntp 服务器在一秒内同步。幸运的是，还有更新的研究；这张纸巴西巴拉那联邦大学的一些作者在 2005 年重复了这项实验，并发现（如果我没有误解他们的图 1）现在 99% 以上（更确切地说是 99.5%）的服务器的偏移量小于 100 毫秒，90% 的服务器的偏移量小于 10 毫秒。这与我的经验非常吻合（见上文）。

编辑2：最后一个问题：所有这些研究都没有调查本地时钟有多准确，而是调查它与上游参考时钟有多大差异。这显然不是一回事。但第一个问题是不可知的；要知道你的时钟有多差，你必须知道现在的确切时间，如果你知道这一点，为什么一开始要把你的时钟调错呢？只要知道这些研究测量的是不是本地时钟与绝对时间之间的差异，而是本地时钟与参考时钟之间的差异。

Answer

没有人能保证 NTP 在您的网络上的运行情况，因为没有人知道您的网络与互联网以及互联网上的时钟服务器的连接情况。但是，根据ntp.org 上的时钟规则算法页面

如果持续运行，家庭或办公室环境中快速 LAN 上的 NTP 客户端可以保持同步，名义上在 1 毫秒内。当环境温度变化小于 1 摄氏度时，即使时钟振荡器的固有频率偏移为 100 PPM 或更高，时钟振荡器频率也会被控制在百万分之一 (PPM) 以内。

请注意，LAN 和互联网时钟服务器之间较大但稳定的延迟对准确性的影响并不像高度可变的延迟那么严重。

您没有说您从哪里得到上述估计值（'50 微秒到......“低于一秒”'），所以我无法对它们发表评论，但根据我的经验，除非您有一个直接连接的时钟源，否则 50 微秒的可能性不大，除非您有一根湿绳将您连接到互联网并且您正在使用南极洲的上游服务器，否则 1 秒的可能性不大。

编辑：你现在在问题中引用的文本指向一篇论文，该论文在 1999 年确实证实了 99% 的 ntp 服务器在一秒内同步。幸运的是，还有更新的研究；这张纸巴西巴拉那联邦大学的一些作者在 2005 年重复了这项实验，并发现（如果我没有误解他们的图 1）现在 99% 以上（更确切地说是 99.5%）的服务器的偏移量小于 100 毫秒，90% 的服务器的偏移量小于 10 毫秒。这与我的经验非常吻合（见上文）。

编辑2：最后一个问题：所有这些研究都没有调查本地时钟有多准确，而是调查它与上游参考时钟有多大差异。这显然不是一回事。但第一个问题是不可知的；要知道你的时钟有多差，你必须知道现在的确切时间，如果你知道这一点，为什么一开始要把你的时钟调错呢？只要知道这些研究测量的是不是本地时钟与绝对时间之间的差异，而是本地时钟与参考时钟之间的差异。

Question 2

您想解决什么问题？

对于需要比 NTP 更高精度的环境，我遇到的解决方案是精确时间协议 (PTP)。我在科学计算和金融计算应用中都遇到过这种情况。权衡，尽管。

另请参阅：centos6/rhel 上的 ptp 时间同步

Answer

您想解决什么问题？

对于需要比 NTP 更高精度的环境，我遇到的解决方案是精确时间协议 (PTP)。我在科学计算和金融计算应用中都遇到过这种情况。权衡，尽管。

另请参阅：centos6/rhel 上的 ptp 时间同步

Question 3

还有几件事值得一提：

如果虚拟机的时钟抖动小于 100ms，那就算幸运了，所以以下所有内容都适用于物理主机
对于几乎所有任务来说，低于 100ms 的抖动几乎是无法测量的，并且可以通过互联网轻松实现
一些通用服务环境可能需要低于 30ms 的抖动（我在之前的工作中需要它来进行日志关联），并且可以轻松使用同一大陆上的 NTP 服务器实现，其中连接不是通过“消费者”链接（例如，不是卫星、ADSL、DOCSIS、GPON、UMTS/LTE/HSPA/等）
为了获得低于此的绝对精度，您应该安装来自优质供应商的硬件 NTP 服务器（例如 Symmetricom）
低于 10 毫秒（通常低于 1 毫秒）当地协议只需在同一个数据中心内拥有三个服务器（也可以更少，但有理由使用三个或五个）即可轻松实现，足以满足几乎所有非科学应用的需求

Answer

还有几件事值得一提：

如果虚拟机的时钟抖动小于 100ms，那就算幸运了，所以以下所有内容都适用于物理主机
对于几乎所有任务来说，低于 100ms 的抖动几乎是无法测量的，并且可以通过互联网轻松实现
一些通用服务环境可能需要低于 30ms 的抖动（我在之前的工作中需要它来进行日志关联），并且可以轻松使用同一大陆上的 NTP 服务器实现，其中连接不是通过“消费者”链接（例如，不是卫星、ADSL、DOCSIS、GPON、UMTS/LTE/HSPA/等）
为了获得低于此的绝对精度，您应该安装来自优质供应商的硬件 NTP 服务器（例如 Symmetricom）
低于 10 毫秒（通常低于 1 毫秒）当地协议只需在同一个数据中心内拥有三个服务器（也可以更少，但有理由使用三个或五个）即可轻松实现，足以满足几乎所有非科学应用的需求

Question 4

我的既得利益：我是 Meinberg 代理商 :-)

是的，如果您将运行 Chrony 或 ntpd 的裸机上的 Linux“客户端”同步到由 GPS、本地原子钟或类似源控制的基于 Linux 的 NTP 服务器，则 NTP 可以实现低至大约 50 us（即微秒）抖动的端到端精度。

在具有本地 GPS（带有 PPS 互连）的机器上，您可能会看到操作系统中运行的 ntpd 实例与其 PPS refclock 驱动程序的输入之间存在 0-2 微秒的偏移。

“LAN 端到端”的剩余 50 微秒是多阶段缓冲、可变 IRQ 延迟、LAN 上和相关计算机总线上的其他流量干扰等因素的结果。50 微秒意味着 LAN 的流量非常小。即使只是一个交换机也会增加几微秒的抖动 - 而具有复杂功能的高端交换机会增加更多的延迟和抖动。换句话说，在实际的 LAN 上，在现实条件下实现这 50 微秒可能非常困难。

类似地，PPS 偏移的 cca <2us 仅仅是由运行良好的 PC 硬件上的 IRQ 延迟不确定性和一般总线延迟抖动造成的。

请注意，NTP 及其实现 ntpd 和 Chrony 肯定会测量 NTP 事务往返时间并减去（实际上是加上）该往返的一半，作为过滤系统传输延迟（单向）的措施。它们还执行异常值拒绝、仲裁共识、系统对等选举，并且任何 NTP 守护程序都会过滤其对上游查询的响应。因此，正如其他人所说，您在 Ping 和 Traceroute 中看到的毫秒数不会直接抵消您的本地时钟。重要的是事务往返的变化，即到上游 NTP 服务器路径上的其他流量。Ntpq -p 是您的好朋友。

带有 TCXO 的用于计时的基本 GPS 接收器，其 PPS 输出可能存在 100-200 纳秒的残余抖动+漂移。只要 GPS 保持锁定，这对于 NTP 来说已经足够好了。（TCXO 的保持性能不是很好。）带有 OCXO 的高质量计时 GPS 的残余误差可能在 100 纳秒以内，可能更像是 10-30 纳秒（与全球 UTC 的偏移）。

请注意，对于接收器来说，实际从头顶飞过并穿过大气层向您发射卫星可能比在实验室中使用 GPS 发生器进行基准测试要困难一些。

PTP 是一把锤子。您需要在主控、从属和任何交换机中获得硬件支持 - 但如果您获得所有这些，则残余偏移量可以低至两位数纳秒。我亲眼见过 ptp4l 在使用具有硬件支持的 i210 NIC 运行时出现这种情况（具有纳秒分辨率的时间戳）。

i210 芯片非常神奇。它有 4 个通用引脚，可用于输入或输出 PPS 信号。带有 i210 的参考英特尔附加 NIC 板（以及来自几家大型供应商的 OEM 版本）配备了一个引脚接头，可让您访问至少 2 个 GPIO 引脚（英特尔称之为 SDP）。除了实现 PTP 大师端口外，PPS 输入还可用于在数据包捕获中实现精确的时间戳。您需要一个精确的 PPS 源和一个自定义软件来运行伺服环路，将 i210 的 PHC 微调到 ext.PPS。在我的测试台上，这导致残差偏移量为个位数 ns（每 1 秒迭代）。如果您在现代 Linux 内核上运行最近的 tcpdump 或 wireshark（所有软件都需要支持纳秒级分辨率），这就是您在捕获时间戳中获得的精度。更好的是：我全力以赴，构建了一个简单的 PLL 合成器，为 NIC 时钟产生 25 MHz，锁定到精确的上游 10MHz 参考。之后，我的数据包捕获设备的伺服环路中的残余偏移量下降到干净的 0（证明我的 10 MHz 参考与来自同一 GPS 盒的 PPS 相位同步）。

请注意，PTP 大师可能被指定为提供每 8 纳秒具有实际粒度的时间戳（在具有 1 纳秒分辨率的数据类型中）。这是有道理的 - 千兆以太网倾向于使用 125 MHz 时钟，用作 MAC 内部的字节时钟，该时钟可能也用于 GMII，并且它也是金属 1000Base-TX 中的符号时钟（四对并行，每对每个符号 2 位）。因此，除非您使用带有 SERDES 的 1000Base-FX（光纤）和 PHY 中 HW 时间戳单元的极端实现（可精确到单个 SERDES 位），否则这 8 纳秒是您在千兆以太网上真正希望的全部。一些芯片数据表（支持 PTP）甚至声称 MII 数据路径并非没有缓冲，并且一些抖动可能来自那里。

PTP 数据包实际上包含以允许深度亚纳秒分辨率的数据类型存储的时间戳。但“亚纳秒小数字段”如今通常未使用。据我所知，到目前为止，只有 White Rabbit 项目（与瑞士研究中心 CERN 相关）实现了亚纳秒精度。

PTP 也可以在纯软件中使用，无需硬件加速。在这种情况下，对于基于 SW 的 GM 和基于 SW 的客户端，预计会得到与 NTP 类似的残余抖动 - 即在专用但不了解 PTP 的 LAN 上约为 50 us。我记得在直接互连（中间没有交换机）和仅 SW 客户端（在不了解 PTP 的 PC NIC 上）上从 HW 大师那里获得了亚微秒的精度。与 NTP 相比，PTP 的伺服收敛速度要快得多。

在做一些“家庭作业”时，我最近想到，通过广域光纤路由传输 PPS 或类似的“离散”定时信号可能会受到与温度相关的传播时间“漂移”的影响。虽然我无法通过实验来测试这一点，但互联网上的一些来源引用了每公里和开尔文 40 到 76 皮秒之间的数字。请注意，虽然这种“热漂移”在单工 PPS 传输中不可能“在带内”缓解，但 PTP 会根据其标准路径延迟测量（取决于全双工传输）固有地对此进行后补偿。

以上就是关于不同计时技术/接口的“精度”的概述。什么级别的精度对您来说足够好，这取决于您的应用和实际需求。

---- 2020 年更新： ----

一位同事最近向我演示了，Chrony 可以在性能良好的 PC 硬件上运行 NTP（无需对其总线时钟振荡器进行特殊处理），并且残余端到端抖动不超过一微秒。这可以在以下条件下观察到：

系统空闲
网络空闲
轮询间隔配置为 1 秒（minpoll=maxpoll=0，我相信）
Chrony 还可以利用硬件时间戳如果可供使用的话

有一个Gentoo 维基页面声称硬件时间戳依赖于与 ptp4l 的共存，对此我表示怀疑（Chrony 自己的文档并未提及）——尽管这对我来说确实有意义，即 NIC 中的 PHC 应该以某种方式进行规范，以使 HW 时间戳有意义……不确定 Chrony 是否可以从带有自由运行时钟的 PHC 中受益。除了 ptp4l，我还可以破解 i210 NIC，使其 25MHz 时钟 PLL 达到精确的频率参考，并将其 PPS 固定到精确的 PPS 参考。但我还没有尝试在其上运行 Chrony :-)

另一个有趣的观察结果：采用 G.8275.2 电信配置文件（即非 White Rabbit）的标准 PTP 可以在不拥塞且优先处理 PTP 流量的现代 MPLS VPN 上实现低两位数纳秒的“漫游”。而且，MPLS 交换机不知道 PTP（不支持路径上）且距离超过约 1000 公里……以 PPS 信号之间的 MTIE 测量 = 最终净结果，从属中的振荡器是高端双炉 OCXO。是的，这实际上意味着理想条件，而现实世界往往是一个残酷的地方。这些数字不是你应该想当然的东西。只是展示了潜力。还请注意，PTP 从属在运行时报告的即时协议抖动比在振荡器的 1PPS 输出处测量的净偏差要差得多。并且，在这些距离/跳数上，您将得到一个巨大的恒定偏移（路径不对称），需要对其进行校准/减去，以使提取的 PPS 信号有任何用处。并且不对称性会随着拓扑结构的变化而变化（路径备份路由开始生效）......

Answer