Jef*_*eff 25 linux ubuntu ntp busybox ntpd
我们在隔离网络上推出 Ubuntu 14.04 服务器，运行 ntpd 4.2.6p5，配置为使用客户提供的多个 NTP 服务器（无法访问 pool.ntp.org）。我们的哑终端客户端设备运行旧版本的 BusyBox (1.00-rc2) 和Larry Doolittle 的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
我的问题是：
ntp.conf吗？那里真的没有什么特别的。hob*_*bbs 28
我看到这里的答案有些混乱。对于初学者来说，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 机器上的输出显示其所有服务器都有数百毫秒的抖动，即使它们的延迟很低，这表明网络非常不可靠，所有服务器都合谋提供不稳定的时间，或基本服务器本身的计时问题。
我还担心服务器 10.31.10.22 正在宣传LOCL（无纪律的本地时钟）的 refid，但层数为 1。通常本地时钟被伪造为 10 层，因此它仅用作最后的同步源防止羊群分散。要么 10.31.10.22 配置错误并为网络的其余部分提供了糟糕的时间，要么它被 NTP 控制之外的某个程序控制到了良好的时间，在这种情况下，错误配置只是因为它正在为LOCLrefid做广告；它应该被覆盖到例如GPS或任何提供它的时间。
Sve*_*ven 12
只是“什么是色散？”的部分答案：
一个典型的NTP往返：
client | | server
t1 |------->| t2
t3 |<-------| t4
这会产生两个值，偏移量（客户端和服务器之间的时间差）和延迟（重要的网络旅行时间），其公式如下：
offset= ((t4 - t3) + (t1 - t2)) / 2
delay = (t4 - t1) - (t3 - t2)
客户端从收到的最后 8 个数据包中选择当前偏移量，选择延迟最小的那个。
通过对这 8 个偏移量与上一步中选择的偏移量的差异进行加权平均，使用相同的 8 个数据包来计算色散，其中延迟用作加权因子，对较小的延迟赋予更大的权重。它是对值“传播”的一种度量，用于计算时间服务器的质量，尤其是在您有多个可供选择的情况下。
您的色散和偏差是巨大的，从本地时钟到该对等点的偏移非常大。您应该将偏移量与本地进行比较date并手动设置时钟。
ntpq -p使用所有对等点从主机运行并显示 ntpd 。它将选择更好的。
根据此 cisco 文档，“离散度，以秒为单位报告，是在本地时钟和服务器时钟之间观察到的最大时钟时间差”。对于未完全损坏的 ntp 服务器，不应出现高度分散的情况。唯一可行的方案是当您的客户端启动 ntp 并且到目前为止只有其本地时钟可用时。即便如此，与您报告的一样高的离散度对应于超过两周的时钟。
通过在 BIOS 中调整时钟（甚至日期！）或ntpdate在启动前发出一次，确保本地时钟在开始时不会太远（即使几个小时仍然可以接受）就足够了ntpd在客户端上。