我有一组四台 ntpd 服务器，它们从同一个 stratum 1 服务器同步时间。但在某些客户端上，它们都标记为 falsetick，为什么？
remote refid st t when poll reach delay offset jitter
==============================================================================
x10.201.24.36 209.51.161.238 2 u 12 64 377 0.177 464.794 1.136
x10.201.13.99 209.51.161.238 2 u 37 64 377 0.148 463.427 0.541
x10.201.24.37 209.51.161.238 2 u 817 1024 377 0.174 462.235 0.143
x10.201.12.198 209.51.161.238 2 u 853 1024 377 0.158 462.151 302.364
*127.127.1.0 .LOCL. 10 l 48 64 377 0.000 0.000 0.004
它们时不时地会恢复，但为什么会发生这种情况？另一个问题是为什么我有这么大的偏移量？我尝试只留下 1 个 ntp 服务器，但偏移量无论如何都不会下降。
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.201.12.198 209.51.161.238 2 u 64 64 7 0.108 470.963 0.200
127.127.1.0 .LOCL. 10 l 136 64 14 0.000 0.000 0.001
我正在运行 CentOS 7，并且所有服务器都在同一个网络中。
ntp.conf：
driftfile /var/lib/ntp/drift
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod limited nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict lga-ntp03.pulse.prod
server lga-ntp03.pulse.prod iburst burst
restrict lga-ntp06.pulse.prod
server lga-ntp06.pulse.prod iburst burst
restrict lga-ntp05.pulse.prod
server lga-ntp05.pulse.prod iburst burst
restrict lga-ntp01.pulse.prod
server lga-ntp01.pulse.prod iburst burst
includefile /etc/ntp/crypto/pw
keys /etc/ntp/keys
更新 #1 删除 LOCL 后（感谢@John Mahowald），我的服务器仍然被标记为 falsetick：
remote refid st t when poll reach delay offset jitter
==============================================================================
x10.201.24.36 209.51.161.238 2 u 886 1024 7 0.177 -330.92 0.172
*10.201.13.99 209.51.161.238 2 u 773 1024 17 0.203 -152.68 0.090
x10.201.24.37 209.51.161.238 2 u 750 1024 17 0.167 94.101 0.468
x10.201.12.198 209.51.161.238 2 u 409 1024 17 0.129 51.831 0.176
答案1
不应使用无纪律的本地时钟 (refid LOCL)。去掉它。
一般情况下不应再使用无纪律的本地时钟。
它最初的设计目的是当 ntpd 必须能够为其他人提供时间时使用，即使没有可访问的实时源。
不守纪律的本地时钟不是叶节点（即仅客户端） ntpd 实例的备份。
理论上，如果 NTP 服务器具有良好的振荡器，它无需任何其他来源就可以提供相当准确的时间。
它失败的原因是大多数计算机上的时钟与包括 NTP 池在内的源相比精度很差。但是，LOCL 的延迟为 0，通常低延迟意味着低错误。因此，您想要使用的可能好的 NTP 源被交集算法丢弃，因为没有一个接近低延迟源。除非本地时钟不是准确的时钟……
460 毫秒的偏移量在许多系统上意味着几天的漂移。这个数字可能更低，但引入 LOCL 时发生了选择问题。此外，如果不进行步进，则需要花费很多小时来约束较大的偏移量。
删除 LOCL 后，根据交叉算法仍然会有异常值。
尽管所有服务器都使用了 refid clock.nyc.he.net，并且都相差 0.2 毫秒，但您的 NTP 服务器彼此之间的偏移量仍然最大为 400 毫秒。这是非常糟糕的性能，考虑到预期误差，标准偏差非常大。
滚动重启服务器上的 ntp 服务。或者强制进行步骤更正。
还要调查您的 NTP 服务器托管在什么服务器上。它们应该负载很轻，除了 ntpd（或 chronyd）之外很少运行。虚拟机是可以接受的，但您需要确保物理主机同步到相同的时间服务。主机时间同步是一件好事。
答案2
正如 John Mahowald 的评论所指出的，您的远程服务器之间没有达成一致。以下是偏移量和延迟值的可视化：
黑色水平条是远程服务器的预计时间，它们应该周围有一些紫色的条，显示远程服务器可能具有的时间值范围。（我们在此图中看不到它们的原因是您与源之间的网络距离非常近。）这些范围应该重叠，但对于源而言，它们并不重叠。
以下是一个工作 NTP 设置的可视化示例：
如您所见，第二个示例的所有中心线都非常靠近（并且接近零偏移），并且重叠范围很大。
所以总结一下就是：您的时间源提供的时间不准确，因此 NTP 理所当然地不信任它们。