这种设置多年来一直很好用,但最近我们遇到了一个新客户的障碍.他们为我们提供了5个内部NTP服务器地址,这些服务器地址看起来效果很好,就ntpdate-debian而言,它与Linux服务器有关.然而,在BusyBox方面,ntpclient抱怨“Dispersion太高”.从调试输出,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服务器获取更多详细信息？
>错误是否存在于ubuntu服务器端,ntp.conf不正确？真的没什么特别的.
>在这种情况下,切换到chrony会改变什么吗？
解决方法
相反,它打印的值是服务器返回的数据包中称为“根色散”(rootdisp)的值,它是该服务器与正确时间之间的错误/方差总量的估计值.计算方法非常简单：每个NTP服务器要么从外部时钟(例如无线电或GPS接收器)或其他NTP服务器获取时间.如果服务器从外部时钟获取时间,则其根分散是该时钟的估计最大误差.如果它从另一个NTP服务器获得时间,它的根分散是服务器的根分散加上它们之间的网络链路添加的分散.
这里有一点令人困惑的是,虽然ntpq和chrony在几秒钟内显示色散和根分散,这是人们习惯看的东西,ntpclient以微秒显示它.无论如何,1217163的值仍然很高.一个好的NTP服务器在几毫秒内知道时间;在几十或几百毫秒内的坏事.你的告诉你它的时间只能在/ – 1.2秒内被信任.
实际上,通过传递-x 0或-t选项(取决于ntpclient的版本),ntpclient可以同步到此服务器,这将禁用NTP健全性检查.如果你只需要大致准确的时间(在几秒钟内),这可能就足够了.但是,ntpclient拒绝同步到这样一个糟糕的服务器是非常合理的.您在ubuntu机器上的ntpq输出显示所有服务器的抖动为几百毫秒,即使它们具有低延迟,这表明网络非常不可靠,所有服务器的阴谋都提供不稳定的时间,或者服务器本身的基本计时问题.
它还让我担心服务器10.31.10.22正在通告一个LOCL(无纪律的本地时钟)的refid,但其层数为1.通常本地时钟被捏造为10层,因此它仅用作最后的同步来源让一群人不要分开. 10.31.10.22配置错误并为网络的其余部分提供了不良时间,或者由于NTP控制之外的某些程序而受到纪律处分,在这种情况下,错误配置只是在宣传LOCL refid;它应该被覆盖到例如GPS或其他任何提供时间的东西.
