我们在隔离的networking上运行Ubuntu 14.04服务器，运行ntpd 4.2.6p5，configuration为使用客户提供的多个NTP服务器（不能访问pool.ntp.org）。 我们的哑terminal客户端设备运行老版本的BusyBox（1.00-rc2）和Larry Doolittle的ntpclient 2010 。
这种设置已经运行了很多年，但是最近我们遇到了一个新客户的障碍。 他们为我们提供了5个内部的NTP服务器地址，就ntpdate-debian而言，他们似乎在自己的工作很好。 然而，在BusyBox方面， ntpclient抱怨“色散太高”。 从debugging输出中， ntpclient从NTP服务器获取“1217163.1”，但它支持的最大值是绝对值（65536）。
$ /usr/sbin/ntpclient -s -i 15 -h 10.17.162.250 -d Configuration: -c probe_count 1 -d (debug) 1 -g goodness 0 -h hostname 10.17.162.250 -i interval 15 -l live 0 -p local_port 0 -q min_delay 800.000000 -s set_clock 1 -x cross_check 1 Listening... Sending ... recvfrom packet of length 48 received Source: INET Port 123 host 10.17.162.250 LI=0 VN=3 Mode=4 Stratum=4 Poll=4 Precision=-20 Delay=60745.2 Dispersion=1346801.8 Refid=10.31.10.21 Reference 3668859928.942079 (sent) 3668859928.708371 Originate 3668859928.708371 Receive 3668859928.963271 Transmit 3668859928.963369 Our recv 3668859928.708371 Total elapsed: 0.00 Server stall: 93.09 Slop: -93.09 Skew: 255443.94 Frequency: 0 day second elapsed stall skew dispersion freq 42463 56728.708 rejected packet: abs(DISP)>65536
这些都是在同一局域网上的所有设备，所以坦率地说，我非常惊讶。 甚至感到害怕
这里是Ubuntu 14.04服务器的ntpq -pn输出：
user@host:~$ ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 127.127.1.0 .LOCL. 10 l 1025 64 0 0.000 0.000 0.000 10.17.162.249 10.17.6.10 5 u 23 1024 37 0.865 1381.07 697.260 10.31.10.22 .LOCL. 1 u 1044 1024 17 29.586 -838.06 397.342 10.17.6.10 10.31.10.21 4 u 1065 1024 17 0.366 105.245 402.999 *10.31.10.21 132.246.11.238 3 u 5 1024 37 29.418 794.292 616.796 10.17.6.11 10.31.10.21 4 u 1038 1024 17 0.408 120.030 381.058
我的问题是：
ntp.conf ？ 真的没有什么特别的。 我在这里看到一些混淆的答案。 对于初学者来说，至less在-s模式下， ntpclient不是一个完整的NTP客户端，它只是发送和接收一个数据包 ，所以没有“最后8个数据包”。 它实际上并不估计它自己的分散。
相反，打印的值是服务器返回的数据包中称为“root dispersion”（rootdisp）的值，它是该服务器与正确时间之间的错误/方差总量的估计值。 计算的方式非常简单：每个NTP服务器从外部时钟（例如无线电或GPS接收器）或其他NTP服务器获取时间。 如果服务器从外部时钟获得时间，则其根分散是该时钟的估计最大误差。 如果从另一个NTP服务器获取时间，则其根分散是服务器的根分散加上它们之间的networking链接所添加的分散。
这里有一点困惑是，ntpq和chrony显示了人们习惯看的离散度和根散度，ntpclient以微秒显示它。 无论如何，1217163的价值还是相当高的。 一个好的NTP服务器可以在几毫秒内知道时间， 在几十或几百毫秒内是不好的。 你的告诉你，它的时间只能在+/- 1.2秒内被信任。
实际上，通过传递-x 0或-t选项（取决于ntpclient的版本），可以使ntpclient同步到此服务器，从而禁用NTP健全性检查。 如果你只需要大致准确的时间（在几秒钟内），那可能就足够了。 但是，ntpclient拒绝同步到这样一个糟糕的服务器是相当合理的。 你的Ubuntu机器上的ntpq输出对于所有的服务器来说都显示出几百毫秒的抖动，尽pipe它们的延迟很低，这表明是一个非常不可靠的networking， 所有服务器的阴谋都是提供不稳定的时间，在服务器本身的基本计时问题。
我也担心服务器10.31.10.22正在通告一个LOCL （无规律的本地时钟）的refid，但层数为1.通常本地时钟被伪造为10的层次，所以它只被用作最后一次同步来源保持一个牧群漂stream。 10.31.10.22configuration错误，给networking的其他部分提供了不好的时间，或者由NTP控制之外的某些程序来惩罚它，这种情况下的错误configuration就是广告LOCL refid; 它应该被覆盖，例如GPS或任何正在提供的时间。
只是“什么是分散？”的部分答案：
典型的NTP往返：
client | | server t1 |------->| t2 t3 |<-------| t4
这产生两个值，偏移量（客户端和服务器之间的时间差），以及延迟（基本的networking旅行时间），具有以下公式：
offset= ((t4 - t3) + (t1 - t2)) / 2 delay = (t4 - t1) - (t3 - t2)
客户端从收到的最后8个数据包中select当前的偏移量，select延迟最小的数据包。
使用相同的8个数据包，通过对这8个偏移量与最后一个步骤中select的偏移量的加权平均值进行加权平均，其中使用延迟作为加权因子，给予较小延迟更大的权重。 这是衡量价值的“传播”，用来计算时间服务器的质量，特别是如果您有多个可供select。
你的分散和倾斜是巨大的，有一个非常大的本地时钟偏移到同行。 您应该将偏移量与本地date进行比较，并手动设置时钟。
运行ntpd并使用所有对等方从主机上显示ntpq -p 。 它会select更好的。
根据这个思科文档 ，“ 散布 ，以秒为单位，是本地时钟和服务器时钟之间观察到的最大时钟时差”。 对于没有完全破坏的ntp服务器，绝不应该发生高度扩散。 唯一可行的scheme是当你的客户端在NTT，并且到目前为止只有它的本地时钟可用。 即使如此，与您报告一样高的离差对应于两周以上的时钟。
通过调整BIOS中的时钟（甚至是date），或者通过在BIOS之前发出ntpdate一次，确保本地时钟在开始时不会太远（即使几个小时仍然可以接受）应该足够了在客户端启动ntpd 。