什么是NTP分散，如何控制它？

我们在隔离的网络上推出了运行ntpd 4.2.6p5的Ubuntu 14.04服务器，这些服务器配置为使用客户提供的多个NTP服务器（无法访问pool.ntp.org）。我们的哑终端客户端设备运行的是Larry Doolittle 的较旧版本的BusyBox（1.00-rc2）和ntpclient 2010。

多年来，这种设置一直有效，但是最近我们遇到了新客户的障碍。他们为我们提供了5个内部NTP服务器地址，ntpdate-debian就Linux服务器而言，它们看起来很不错。但是在BusyBox方面，ntpclient抱怨“色散太高”。从调试输出中，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

这些都是同一局域网上的所有设备，所以坦率地说，我感到非常惊讶。吓坏了

这是ntpq -pnUbuntu 14.04服务器的输出：

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

我的问题是：

1. 什么是色散，什么可以改变其价值？
2. 我可以运行哪些命令以从NTP服务器获取更多详细信息？
3. 故障可能出在Ubuntu服务器端ntp.conf吗？真的没有什么特别的。
4. 在这种情况下，切换到时间顺序会有所改变吗？

我看到这里的答案有些混乱。对于初学者来说，ntpclient至少在-s模式下，它不充当完整的NTP客户端，它仅发送和接收一个数据包，因此没有“收到的最后8个数据包”。实际上，它根本没有估计其自身的分散性。

相反，它输出的值是服务器返回的数据包中称为“根散度”（rootdisp）的值，它是该服务器与正确时间之间的总误差/方差的估计值。计算方法非常简单：每个NTP服务器都从外部时钟（例如，无线电或GPS接收器）或另一个NTP服务器获取时间。如果服务器从外部时钟获取时间，则其根偏差是该时钟的估计最大误差。如果它是从另一台NTP服务器获取时间，则其根目录分散是该服务器的根目录分散加上它们之间网络链接所添加的分散。

令人困惑的一点是，虽然ntpq和chrony以秒为单位显示了色散和根色散，这是人们习惯的，但ntpclient却以微秒为单位显示它。无论如何，值1217163仍然很高。一个好的NTP服务器可以在几毫秒内知道时间。几十或几百毫秒内发生的故障。您告诉您，时间只能信任+/- 1.2秒以内。

实际上，通过传递-x 0or -t选项（取决于ntpclient的版本），实际上可以使ntpclient同步到该服务器，该选项禁用NTP完整性检查。如果您只需要大致准确的时间（几秒钟之内），那可能就足够了。但是，ntpclient在拒绝同步到如此糟糕的服务器方面非常合理。ntpq尽管ubuntu机器上的所有服务器延迟很短，但您在ubuntu机器上的输出却显示出数百毫秒的抖动，这表明网络非常不可靠，所有服务器串谋提供不稳定的时间，或者基本服务器本身的计时问题。

我还担心服务器10.31.10.22的refid为LOCL（未纪律的本地时钟），但层数为1。通常，本地时钟被捏造为10层，因此它仅用作最后一种同步源防止一群人分开。可能是10.31.10.22配置错误并为网络的其余部分提供了不好的时间，或者是由于NTP无法控制的某个程序将其限制为良好的时间，在这种情况下，错误配置仅是因为它在宣传LOCLrefid。它应该被覆盖为例如GPS或提供时间的任何内容。

对于“什么是分散？”仅作部分回答：

典型的NTP往返：

client |        | server
    t1 |------->| t2
    t3 |<-------| t4

这将产生两个值，偏移量（客户端和服务器之间的时间差）和延迟（基本的网络传输时间），其计算公式如下：

offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)

客户端从接收到的最后8个数据包中选择当前偏移量，并选择延迟最小的数据包。

相同的8个数据包通过对这8个偏移量的差值与最后一步中选择的偏移量进行加权平均来计算色散，其中将延迟用作加权因子，将较大的权重赋予较小的延迟。它是对值“散布”的度量，用于计算时间服务器的质量，尤其是在您有多个选择的情况下。

您的分散和偏斜非常大，本地时钟到该对等方的偏移很大。您应该将偏移量与本地偏移量进行比较，date并手动设置时钟。

使ntpd运行，并ntpq -p使用所有对等方从主机显示。它将选择更好的。

根据此cisco文档，“ 色散（以秒为单位）是本地时钟与服务器时钟之间观察到的最大时钟时间差”。对于没有完全损坏的ntp服务器，永远不会出现高度分散的情况。唯一可行的方案是当您的客户端启动ntp时，到目前为止只有其本地时钟可用。即使这样，与您报告一样高的离差对应于两个星期以上的时钟偏离。

通过在BIOS中调整时钟（甚至连日期！）或通过ntpdate在启动前发出一次时钟，足以确保开始时本地时钟不会太远（甚至几个小时仍然可以接受）。ntpd在客户端上。