通常，当一台机器完全失去连接时，ntpd会错过几次民意调查，并将所有来源标记为失败。 这似乎很合乎逻辑。 但是，当服务器保持标记为当前时间源，而其覆盖范围变为0时，我遇到了一种情况。
Sever部署在与目标机器相同的子网中，提供非常低的延迟，偏移和抖动。 这种情况是通过closures物理连接来模拟的：只需从客户机上拔下一根电源线即可。 我试图重新创build这个，但从那以后，同样的机器在5-6次不成功的民意调查之后总是失去同步状态。
真正的问题是：当连接丢失时，究竟是什么决定了同步状态？
在RFC-1305中有一个关于覆盖寄存器的详细解释：
可达性寄存器向左移动一个位置，用空位replace零。 如果此寄存器的所有位都为零，则调用清除过程以清除时钟filter，并在必要时重新select同步源。 如果关联没有通过初始化程序configuration，则关联被复员。
RFC-1305如何被RFC-5905淘汰，这并不是那么有意义：
接下来，第13节所述轮询过程中的8位p.reach移位寄存器用于确定服务器是否可访问且数据是否新鲜。 发送数据包时，寄存器左移一位，最右边的位设置为零。 当有效数据包到达时，最右边的位被设置为1。 如果寄存器包含任何非零位，则服务器被视为可访问; 否则，它是不可达的。
第13节没有提到明确的程序。但是，看起来像一个不可思议的同行在某个时候应该放弃同步。
我已经设法重build同步状态达到0的情况，以确保这是罕见的，而不是永久的。 它在服务器configuration中禁用了“突发”，并在同步之后立即断开连接。
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个民意调查来build立同步。
然后同步失去了这个姿势：
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次不成功的民意调查来打破同步状态。
因此，从理论和实践的angular度来看，它看起来就像是一个0到达的源可能被认为是现在的时间源是可能的，但也是罕见的和暂时的。