是否有关于NTP准确性的研究材料？

据我所知，NTP同步的准确性在很大程度上取决于网络。我在互联网上看到了一些从50微秒到“一秒钟以下”的数字。好吧，这是一个巨大的差异。

我认为，精度依赖是一个需要研究的大问题，但是到目前为止，我没有找到任何材料，它清楚地表明，例如，某些特定的配置可以赋予该特定的精度。

在http://www.ntp.org/ntpfaq/NTP-s-algo.htm上说：

服务器和客户端之间的时间差要求小于128毫秒，以保持NTP同步。Internet上的典型精度范围为5毫秒至100毫秒，可能会随网络延迟而变化。最近的一项调查[2]表明90％的NTP服务器的网络延迟低于100毫秒，并且大约99％的NTP服务器在1秒钟内同步到同步对等方。

通过PPS同步，可以在奔腾PC（例如运行Linux）上实现50µs的精度和低于0.1 PPM的稳定性。

就是这样，但也许对此主题有一些更详尽的分析？

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

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

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

您不会说您在何处获得了上述估算值（“ 50微秒到...”低于“一秒””），因此我无法对此进行评论，但根据我的经验，除非您直接购买，否则50us不太可能时钟源，除非您有一条湿线将您连接到互联网并且正在使用南极洲的上游服务器，否则不太可能使用1s。

编辑：您现在在问题中引用的文本提供了指向该论文的指针，该论文在1999年确实确定了99％的ntp服务器在1秒钟内同步。幸运的是，还有更多的工作要做。在本文中，来自巴西巴拉那联邦大学的一些作者在2005年重复了该实验，发现（如果我正确理解了他们的图1），现在99％的服务器（更像是99.5％的服务器）以北的偏移量小于100ms，并且90％的偏移量小于10ms。这与我的经验非常吻合（见上文）。

编辑2：最后一个皱纹：所有这些研究都没有研究本地时钟的准确度，而是与上游参考时钟相差多远。这些显然不是同一回事。但是第一个是不可知的。要知道您的时钟有多错误，您必须确切地知道现在的时间，如果知道的话，为什么首先要设置错误的时钟？请注意，这些研究测量的不是本地时钟和绝对时间之间的差异，而是本地时钟和参考时钟之间的差异。

您要解决什么问题？

对于要求比NTP更精确的环境，我遇到的解决方案是精确时间协议（PTP）。我在科学计算和金融计算应用程序中都有它。不过，还有一些权衡。

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

值得一提的其他几件事：

• 您将很幸运在虚拟机上获得小于100ms的时钟抖动，因此以下所有内容都是针对物理主机的
• 对于几乎所有任务而言，不到100毫秒的抖动几乎都是无法测量的，并且可以通过Internet轻松实现
• 在某些一般服务环境中，可能需要30毫秒以下的抖动（我在上一份工作中需要日志关联），并且可以使用不在通过“消费者”链接（例如，不是卫星）进行连接的同一大陆上的NTP服务器轻松实现抖动，ADSL，DOCSIS，GPON，UMTS / LTE / HSPA /等）
• 为了达到此绝对精度，您应该安装来自优质供应商（例如Symmetricom）的硬件NTP服务器
• 只需在同一数据中心内放置三重奏（您可以用更少的功夫，但有理由使用三个或五个）就足以轻松满足亚10毫秒（通常小于1毫秒）的本地协议，几乎可以满足几乎所有非科学应用程序的需求

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

是的NTP可以实现低至约100的端到端精度。如果您将运行Chrony或ntpd的裸机上的Linux“客户端”同步到受GPS，本地原子钟或某些此类来源约束的基于Linux的NTP服务器，则将产生50 us（微秒）的抖动。

在具有本地GPS（具有PPS互连）的计算机上，您可能会看到OS中运行的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是一把锤子。您需要在主时钟，从时钟以及在任何开关中都需要硬件支持-但是如果您有足够的支持，则残余偏移量可能会降低至低的两位数纳秒。我亲自在运行有硬件支持的i210 NIC的ptp4l中看到了这一点（时间戳的分辨率为纳秒）。

i210芯片是一个奇迹。它具有4个通用引脚，可用于输入或输出PPS信号。带有i210的参考Intel附加NIC板（及其多家大型供应商的OEM版本）配备了一个插针接头连接器，使您可以访问至少两个这些GPIO插针（SDP被Intel称为）。除了实现PTP超级主端口外，还可以利用PPS输入在数据包捕获中进行精确的时间戳记。您需要精确的PPS来源和自定义的软件来运行伺服环路，从而将i210的PHC微调到ext.PPS。在我的测试平台上，这导致残余偏移量达到单位ns（每1 s迭代）。这就是您在捕获时间戳记中获得的精度，如果您在现代Linux内核上运行最新的tcpdump或Wireshark（所有软件都需要支持纳秒级分辨率）。更好的是：我一直努力并构建了一个简单的PLL合成器，以为NIC时钟产生25MHz的频率，并锁定在精确的上游10MHz参考上。之后，我的数据包捕获设备的伺服环路中的剩余偏移量降为零（证明我的10 MHz参考与同一GPS盒中的PPS相位同步）。

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

PTP数据包实际上包含以某种数据类型存储的时间戳，该数据类型允许深度亚纳秒的分辨率。但是，如今，“亚纳秒分数场”通常未被使用。迄今为止，只有白色兔子项目（与CERN的瑞士研究中心有关）才实施了ns-ns精度。

PTP也可在纯软件中使用，而无需硬件加速。在那种情况下，对于基于SW的GM和基于SW的客户端，期望获得与NTP类似的残留抖动-即在专用但不支持PTP的LAN上大约50 us。我记得在直接互连（在它们之间没有切换）和仅SW的客户端（在不知道PTP的PC NIC上）上，从硬件大师获得的亚微秒精度。与NTP相比，PTP的伺服收敛更快。

在做一些“作业”时，我最近发现在广域光纤路径上传输PPS或类似的“离散”定时信号可能会受到温度依赖的传播时间“漂移”的影响。尽管我无法通过实验进行测试，但互连网上的某些消息来源的数据是每公里和开尔文介于40到76皮秒之间。请注意，虽然这种“热漂移”不可能减轻单工PPS传输中的“带内”，但PTP会根据其标准路径延迟测量值（取决于全双工传输）对其进行固有的后补偿。

在不同的计时技术/接口下，“规则”的外观概述非常重要。哪种精度水平对您足够好，取决于您的应用程序和实际需求。