通常，当一台机器完全失去连接时，ntpd 会错过几次轮询并将所有源标记为失败。这似乎很合乎逻辑。但我遇到过一种情况，当服务器的覆盖范围变为 0 时，它仍被标记为当前时间源。
服务器与目标机器部署在同一个子网中，提供非常低的延迟、偏移和抖动。这种情况是通过物理关闭连接来模拟的：只需从客户端机器上拔下电源线即可。我尝试重新创建这种情况，但从那时起，同一台机器在 5-6 次轮询失败后总是会很好地失去同步状态。
真正的问题是：当连接丢失时，究竟是什么决定了同步状态？
答案1
RFC-1305中对到达寄存器有明确的解释：
可达性寄存器向左移动一位，用零替换空出的位。如果此寄存器的所有位均为零，则调用清除过程来清除时钟滤波器并重新选择同步源（如有必要）。如果初始化过程未配置关联，则解除关联。
然而 RFC-1305 已经被 RFC-5905 取代，而 RFC-5905 并不那么具有决定性：
接下来，使用第 13 节中描述的轮询过程中的 8 位 p.reach 移位寄存器来确定服务器是否可访问且数据是否新鲜。发送数据包时，寄存器左移一位，最右边的位设置为零。当有效数据包到达时，最右边的位设置为 1。如果寄存器包含任何非零位，则认为服务器可访问；否则，服务器不可访问。
第 13 节中没有提到明确的程序。但看起来无法连接的对等方在某些时候应该会失去其同步状态。
我已成功重建同步状态，并达到 0 的情况，以确保这种情况很少见，而且根本不是永久性的。这需要在服务器配置中禁用“突发”，并在同步后立即断开连接。
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 20 64 177 51.137 -2.192 11.049
192.168.1.1 193.67.79.202 2 u 65 64 77 0.459 -1.818 0.922
remote refid st t when poll reach delay offset jitter
==============================================================================
*91.198.10.4 194.190.168.1 2 u 21 64 177 51.137 -2.192 11.049
+192.168.1.1 193.67.79.202 2 u - 64 177 0.449 -3.192 1.828
范围是 177，用二进制表示为 01111111。因此需要 7 次轮询才能建立同步。
然后在这个位置同步丢失：
remote refid st t when poll reach delay offset jitter
==============================================================================
+91.198.10.4 194.190.168.1 2 u 574 64 0 63.846 -9.652 0.756
*192.168.1.1 193.67.79.202 2 u 553 64 0 0.449 -3.192 0.505
remote refid st t when poll reach delay offset jitter
==============================================================================
91.198.10.4 194.190.168.1 2 u 575 64 0 69.871 -10.409 0.002
192.168.1.1 193.67.79.202 2 u 554 64 0 0.449 -3.192 0.505
当数字有点奇怪时，例如 64*9 = 576 而不是 575，但我猜，表示可能不准确 1 秒。考虑到这一点，需要 9 次不成功的轮询才能打破同步状态。
因此，从理论和实践两个角度考虑，将 0 覆盖范围的源视为当前时间源似乎是可能的，但也很罕见且是暂时的。