据我所知，NTP 同步的准确性在很大程度上取决于网络。我在互联网上看到过一些从 50 微秒到“低于一秒”的数字。嗯，这是一个巨大的差异。
我相信，准确性相关性是一个值得研究的好问题，但到目前为止，我没有找到任何材料，明确指出，例如，某些特定的配置会授予特定的准确性。
在http://www.ntp.org/ntpfaq/NTP-s-algo.htm上说：
服务器和客户端之间的时间差需要小于 128 毫秒才能保持 NTP 同步。Internet 上的典型精度范围从大约 5 毫秒到 100 毫秒，可能会随网络延迟而变化。最近的一项调查[2]表明 90% 的 NTP 服务器的网络延迟都在 100ms 以下，大约 99% 会在一秒内同步到同步对等方。
通过 PPS 同步，在 Pentium PC（例如运行 Linux）上可以实现 50µs 的精度和低于 0.1 PPM 的稳定性。
确实如此，但也许对这个话题有更彻底的分析？
Mad*_*ter 18
没有人能保证 NTP 在您的网络上工作得有多好，因为没有人知道您的网络与 Internet 及其上的时钟服务器的连接有多好。但是，根据ntp.org 上的时钟纪律算法页面
如果持续运行，家庭或办公室环境中快速 LAN 上的 NTP 客户端名义上可以在一毫秒内保持同步。当环境温度变化小于摄氏 1 度时，时钟振荡器频率控制在百万分之一 (PPM) 以内，即使时钟振荡器本机频率偏移为 100 PPM 或更多。
请注意，您的 LAN 和互联网时钟服务器之间的大而稳定的延迟对准确性的影响并不像高度可变的延迟那样严重。
你没有说你从哪里得到上面的估计（'50 微秒到......“低于一秒”'），所以我不能对它们发表评论，但根据我的经验，50us 不太可能，除非你有一个直接附加的时钟源，除非您有一条湿线将您连接到互联网并且您在南极洲使用上游服务器，否则 1s 不太可能。
编辑：您现在在问题中引用的文本指向了一篇论文，该论文在 1999 年确实确定 99% 的 ntp 服务器在一秒内同步到。幸运的是，还有更多最近的工作；在这篇论文中，巴西巴拉那联邦大学的一些作者在 2005 年重复了这个实验，并发现（如果我正确理解他们的图 1），99% 以北的服务器——更像是 99.5%——现在的偏移量小于100 毫秒，而 90% 的偏移量小于 10 毫秒。这非常符合我的经验（见上文）。
编辑 2：最后一个问题：所有这些研究都没有研究本地时钟的准确度，而是研究它与上游参考时钟的差异有多大。这些显然不是一回事。但第一个是不可知的；要知道你的时钟有多错，你必须确切地知道现在几点了，如果你知道这一点，你为什么一开始就把时钟调错了？请注意，这些研究测量的不是本地时钟和绝对时间之间的差异，而是本地时钟和参考时钟之间的差异。
eww*_*ite 11
你想解决什么问题？
对于需要比 NTP 更精确的环境，我遇到的解决方案是Precision Time Protocol (PTP)。我已经在科学计算和金融计算应用程序中使用过它。不过也有取舍。
还有一些值得一提的事情：
我的既得利益：我是 Meinberg 经纪人 :-)
是的，NTP 可以实现低至约 100 秒的端到端精度。如果您将运行 Chrony 或 ntpd 的裸机上的 linux“客户端”同步到由 GPS、本地原子钟或某些此类源控制的基于 Linux 的 NTP 服务器，则抖动为 50 us（即微秒）。
在具有本地 GPS（带有 PPS 互连）的机器上，您可能会看到在操作系统中运行的 ntpd 实例与其 PPS refclock 驱动程序的输入之间存在 0-2 微秒的偏移。
那些剩余的 50 us“通过 LAN 端到端”是几个阶段的缓冲、可变 IRQ 延迟、LAN 上的其他流量干扰以及所涉及的计算机总线等等的结果。50 us 表示 LAN 流量很少。即使只是一个交换机也会增加几微秒的抖动——而具有复杂功能的高端交换机会增加更多的延迟和抖动。换句话说，在某些实际 LAN 上的实际条件下实现这 50 微秒可能非常困难。
类似地，那些 cca <2us 的 PPS 偏移仅由性能良好的 PC 硬件上的 IRQ 延迟不确定性和一般总线延迟抖动造成。
请注意，NTP 及其实现 ntpd 和 Chrony 肯定会测量 NTP 事务往返时间并减去（实际上）该往返的一半，作为过滤掉系统传输延迟（一种方式）的一种措施。他们还执行异常拒绝、仲裁共识、系统对等选举和任何 NTP 恶魔过滤它对上游查询的响应。正如其他人所说，您在 Ping 和 Traceroute 中看到的毫秒数不会直接抵消您的本地时钟。重要的是交易往返的可变性，即通往上游 NTP 服务器的路径上的其他流量。Ntpq -p 是你的朋友。
带有 TCXO 的用于计时的基本 GPS 接收器在其 PPS 输出上可能具有 100-200 ns 的残余抖动 + 漂移。只要 GPS 保持锁定状态，对于 NTP 来说就足够了。（TCXO 的保持性能不是很好。）带有 OCXO 的高质量定时 GPS 可以在 100 ns 以内，可能更像是 10-30 ns 的残余误差（与全球 UTC 的偏移）。
请注意，与在实验室中使用 GPS 发生器进行基准测试相比，实际从头顶飞过并穿过大气层向您发射的卫星对于接收器来说可能是一个稍微困难的游戏。
PTP是一把锤子。您需要在大师级、从机和任何交换机中提供硬件支持——但如果你得到了所有这些，残留偏移量低至两位纳秒是可能的。我个人在 ptp4l 中看到了这一点，它与具有硬件支持的 i210 网卡一起运行（具有纳秒分辨率的时间戳）。
i210 芯片是一个奇迹。它有 4 个通用引脚，可用于输入或输出 PPS 信号。带有 i210 的参考 Intel 附加 NIC 板（及其来自几家大供应商的 OEM 版本）配备了一个针头，可让您访问至少 2 个 GPIO 针（英特尔称为 SDP）。除了实现 PTP 主端口外，PPS 输入还可用于数据包捕获中的精确时间戳。您需要精确的 PPS 源和定制的软件来运行伺服回路，将 i210 的 PHC 微调到 ext.PPS。在我的测试台上，这导致了个位数 ns（每 1 秒迭代）的残余偏移。这是您在捕获时间戳中获得的精度，如果您在现代 Linux 内核上运行最近的 tcpdump 或 wireshark（所有软件都需要支持纳秒级分辨率）。更好的是：我一路构建了一个简单的 PLL 合成器来为 NIC 时钟产生 25 MHz，锁定到一个精确的上游 10 MHz 参考。在那之后，我的数据包捕获设备的伺服回路中的残余偏移量下降到一个干净的 0（证明我的 10 MHz 参考与来自同一个 GPS 盒的 PPS 相位同步）。
请注意，可以指定 PTP 大师来提供具有每 8 ns 实际粒度的时间戳（在具有 1 ns 分辨率的数据类型中）。这是有道理的 - 千兆以太网倾向于使用 125 MHz 时钟，用作 MAC 内部的字节时钟，该时钟可能也用于 GMII，它也是金属 1000Base-TX（四对并行，每对每个符号 2 位）。因此，除非您使用带有 SERDES 的 1000Base-FX（光纤）以及 PHY 中硬件时间戳单元的极端实现，该单元适用于单个 SERDES 位，否则在千兆以太网上，这 8 ns 是您真正希望的全部。一些芯片数据表（支持 PTP）甚至声称 MII 数据路径不是没有缓冲的，一些抖动可能来自那里。
PTP 数据包实际上包含以允许深亚纳秒分辨率的数据类型存储的时间戳。但是“亚纳秒分数域”现在通常未使用。AFAIR 到目前为止，只有 White Rabbit 项目（与瑞士研究中心 CERN 相关）实现了亚纳秒精度。
PTP 也可以在纯软件中使用，没有硬件加速。在这种情况下，对于基于 SW 的 GM 和基于 SW 的客户端，期望获得与 NTP 类似的残余抖动 - 即在专用但不知道 PTP 的 LAN 上大约 50 us。我记得在直接互连（中间没有开关）和纯软件客户端（在 PTP 不感知 PC NIC 上）上从硬件大师那里获得亚微秒精度。与 NTP 相比，PTP 的伺服收敛速度要快得多。
在做一些“家庭作业”时，我最近突然想到，通过广域光纤路由传输 PPS 或类似的“离散”定时信号可能容易受到温度相关传播时间“漂移”的影响。虽然我无法通过实验来测试这一点，但互联网上的一些来源引用了每公里 40 到 76 皮秒和开尔文之间的数字。请注意，虽然这种“热漂移”无法在单工 PPS 传输中缓解“带内”，但 PTP 会根据其标准路径延迟测量（取决于全双工传输），对这种情况进行固有的后补偿。
关于不同计时技术/接口的“精度”的概述就到此为止。什么级别的精度对您来说足够好，这取决于您的应用程序和您的实际需求。
---- 2020 年更新：----
一位同事最近向我证明，Chrony 可以在性能良好的 PC 硬件上运行 NTP（对其总线时钟振荡器没有特殊处理），并具有微秒或更短的残余端到端抖动。这可以在以下条件下观察到：
有一个Gentoo wikipage声称硬件时间戳取决于与 ptp4l 的共存，我对此表示怀疑（Chrony 自己的文档没有建议） - 尽管对我来说确实有意义，NIC 中的 PHC 应该以某种方式对硬件进行纪律处分时间戳很有意义……不确定 Chrony 是否可以从具有自由运行时钟的 PHC 中受益。除了 ptp4l，我还可以破解 i210 网卡，使其 25MHz 时钟 PLL 连接到精确的频率参考，并将其 PPS 连接到精确的 PPS 参考。不过，我还没有尝试在此之上运行 Chrony :-)
另一个有趣的观察结果：具有 G.8275.2 电信配置文件（即不是白兔）的标准 PTP 可以通过现代 MPLS VPN 实现低两位数纳秒的“漫游”，该 VPN 不拥塞并优先考虑 PTP 流量。那，在 MPLS 交换机不知道 PTP（无路径支持）和超过约 1000 公里的距离的情况下......测量为 PPS 信号之间的 MTIE = 最终净结果，并且从机中的振荡器是高端双倍-烤箱OCXO。是的，这实际上意味着理想的条件，而现实世界往往是一个残酷的地方。这些数字不是你应该想当然的。只是展示了潜力。另请注意，PTP 从设备在运行时报告的即时协议抖动比在振荡器的 1PPS 输出处测得的净偏差要差得多。和，在这些距离/跳数上，您将得到一个很大的恒定偏移（路径不对称），需要校准/减去提取的 PPS 信号才能使用。并且不对称性会随着拓扑变化而改变（路径备份路由开始起作用）......