我正在调查与 NTP 和时间同步操作相关的系统故障。这个问题很难重复，所以我只是做了一些健全性检查，看看不同的条件是否会产生预期的结果。
我的问题是关于 ntpq 使用的对等状态报告，以及我在某些条件下看到的情况是否合理。正如我将进一步解释的那样，我很难理解 ntpq 对等报告如何正确。
我在 Unix/Linux 网站上提问是因为我对正常行为感兴趣，并且我假设 NTP 源自 Unix。但为了完整起见，此 ntpq 和 ntp 守护程序在 Windows Server 上运行（如果这很重要，则使用 Meinberg 的第三方软件）。
工作假设是 NTP 服务器无法以某种方式响应，从而导致可能存在缺陷的故障转移情况（切换到另一个源）。下面的步骤旨在看看我们是否可以强制发生类似的失败。
（顺便说一句，在下面的说明中，连接和断开只需在相应服务器上连接或断开以太网电缆即可完成。）
连接一台 NTP 服务器，断开一台 NTP 服务器，加上本地内部故障转移时基源，运行 ntpq 给出以下结果，其中对等报告如下所示（包括我的注释：
* 192.168.a.b *this is the connected time server*
192.168.c.d *this is the disconnected time server*
127.127.1.0
然后所选对等点（由星号表示）断开连接，几分钟后 ntpq 报告
192.168.a.b *this has been disconnected*
192.168.c.d *this is still not yet connected*
* 127.127.1.0 *this is what I would expect*
第一个NTP服务器重新连接，ntpq报告原来的状态
* 192.168.a.b *this has been reconnected*
192.168.c.d *this is still not connected*
127.127.1.0
然后连接第二个 NTP 服务器。几分钟后 (3-4)，ntpq 报告
x 192.168.a.b *this is still connected*
x 192.168.c.d *this is now connected for the first time in this test*
127.127.1.0
请注意，我们之前从未注意到“x”，但根据ntp编程手册，这意味着服务器是一个“假标记”：“对等点被交集算法作为假标记丢弃”。
问题：为什么原来选择的peer没有被选中？此时使用哪个计时源？
然后第一台服务器就断开了。
那时，ntpq 不会运行，我们得知 ntpd 已经死了。所以我们重新启动ntp服务并继续。
现在，ntpq 和 ntpd 再次运行，等待几分钟后，ntpq 报告
* 192.168.a.b *but this is not connected!*
+ 192.168.c.d *this is still not connected*
127.127.1.0
断开连接的 NTP 服务器已被声明为选定的对等方！据报告，正在运行并连接的第二个 NTP 服务器是候选者：“对等方是幸存者，也是组合算法的候选者。”
问题：为什么断开连接的 NTP 服务器会被声明为选定的对等方？此时使用哪个计时源？
虽然这一系列事件只是为了看看我们是否可以强制最初的失败，但事实并非如此。但它确实产生了一些意想不到的结果，这些结果可能表明某些因素导致了最初的问题。同样有趣的是，到目前为止，系统继续不间断地运行，没有报告任何 ntp 相关问题，也没有显示原始故障的任何其他症状。
第一个服务器是商用 GPS 驱动的时间服务器。第二台服务器在其自己的独立硬件上的虚拟机上运行（目前我没有其他详细信息。）