据我所知,这对NTP来说是一个很高的订单,因为NTP通常希望与多台服务器联系.我在机器B上正常工作时遇到了麻烦.机器A与GPS同步很好,机器B可以到达机器A甚至做时间查询,但机器A不受信任(可能是它本身？).机器A运行一小时后,突然发生变化,机器B工作.然而,当机器A停机(因此机器B)时,机器B再次无法找到良好的时间同步.
这是一些ntpdate信息.请注意,即使机器A的层数为1,操作也会以最后相同的输出失败.
10.10.10.1: Server dropped: strata too high
server 10.10.10.1,port 123
stratum 16,precision -19,leap 11,trust 000
refid [10.10.10.1],delay 0.02614,dispersion 0.00000
transmitted 4,in filter 4
reference time: 00000000.00000000 Thu,Feb 7 2036 6:28:16.000
originate timestamp: d3a9bdc4.27ebb350 Thu,Jul 12 2012 21:19:00.155
transmit timestamp: bc17c803.b42dfffe Sat,Jan 1 2000 0:25:39.703
filter delay: 0.02625 0.02614 0.02618 0.02625
0.00000 0.00000 0.00000 0.00000
filter offset: 39544160 39544160 39544160 39544160
0.000000 0.000000 0.000000 0.000000
delay 0.02614,dispersion 0.00000
offset 395441600.451568
1 Jan 00:25:39 ntpdate[677]: no server suitable for synchronization found
我的猜测是机器A只是不相信自己的服务时间.经过51分钟(可能早先发生,我不知道)的正常运行时间和时钟同步到GPS,机器A开始正常服务时间,机器B捡起它.我需要提前做到这一点.比如,如果可能,在几秒钟内.
通过以下配置(以及大量等待),它最终会成功.
机器A ntp.conf：
server 127.127.28.0 prefer true minpoll 4 maxpoll 4 fudge 127.127.28.0 stratum 1 time1 0.420 refid GPS
机器B ntp.conf：
server 10.10.10.1 prefer true minpoll 4 maxpoll 4
机器B上的ntpq -c peer没有很好的时间修复：
remote refid st t when poll reach delay offset jitter ============================================================================== 10.10.10.1 .STEP. 16 u 9 16 0 0.000 0.000 0.000
机器B上的ntp1 -c对等机具有良好的时间修复：
remote refid st t when poll reach delay offset jitter ============================================================================== *10.10.10.1 SHM(0) 2 u 7 16 17 0.669 2.597 1.808
所以,现在问题变成了：我如何快速地使机器A信任？
在机器B之前和之后机器A的一些调试输出决定机器A足够好用.
之前..
~ # ntpq -c rv associd=0 status=c418 leap_alarm,sync_uhf_radio,1 event,no_sys_peer,version="ntpd 4.2.6p4@1.2324 Fri Feb 24 15:01:45 UTC 2012 (1)",processor="armv7l",system="Linux/2.6.35.14",leap=11,stratum=2,precision=-19,rootdelay=0.000,rootdisp=44.537,refid=SHM(0),reftime=d3ab0053.43b44780 Fri,Jul 13 2012 20:15:15.264,clock=d3ab0062.e7e03154 Fri,Jul 13 2012 20:15:30.905,peer=34819,tc=4,mintc=3,offset=0.000,frequency=0.000,sys_jitter=3.853,clk_jitter=36.492,clk_wander=0.000
后…
~ # ntpq -c rv associd=0 status=0415 leap_none,clock_sync,leap=00,rootdisp=41.278,reftime=d3ab0063.43b37856 Fri,Jul 13 2012 20:15:31.264,clock=d3ab006d.9ee53ec2 Fri,Jul 13 2012 20:15:41.620,frequency=43.896,sys_jitter=0.762,clk_jitter=36.953,clk_wander=0.000
解决方法
考虑在两个系统上使用硬件时钟作为备用时间源.设置更高的层次系统B.以下内容应该有效：
server 127.127.1.0 fudge 127.127.1.0 stratum 8
观察ntpq -c peer的输出以查看何时获得可信时钟源.通常,ntp在信任它之前需要来自可信时间源的大量响应.这由每行的第一个字符表示.
虽然NTP喜欢更多来源,但是在一个层次中任何奇数个时间源都应该运行良好.由于您只有两台服务器和一个GPS时钟,因此源的优先级(层数)应该从GPS,服务器A上的时钟,服务器B上的时钟增加.将每个层之间的层数增加三层或四层将确保优先级得到尊重.
编辑：如果您在服务器A上有busyBox NTP服务器,则可能值得安装完整的ntp服务器软件包.了解服务器A的情况应该可以解决您的问题.在服务器B应该信任它之前,您将需要至少一个受信任的时间源.如果ntpq -c peers不起作用,那么你可以试试ntpdc peer.这两个命令都允许您查询其他主机. peerstats日志也很有用.
在服务器B上使用ntpclient记录busybox ntp howto来记录它上面发生的事情
如果服务器没有长时间停机,时钟应该合理地接近正确的时间.如果您需要同步这两个系统,那就足够了. GPS将最终使时间与现实世界同步.
‘ntpd -q’快速同步,但退出(ntpdate行为).它需要后跟一个没有quit选项的ntpd命令才能进行连续同步.
EDIT2：我检查了我的服务器,发现其中一台服务器关闭了一秒钟.在修复此问题时,我使用了设置. iburst非常快速地获得服务器信任.如果没有多个其他可信来源,则确保时钟驱动程序受信任.时钟花了不到一分钟才被本地信任,可以远程信任.
在测试时,您应该能够在同步后重新启动ntpd进程并测试设置的工作速度.在上述情况下,可能需要重新启动服务器B以测试其同步的速度.监视ntpd更改时,我使用如下行：
while ntpq -c peers localhost; do sleep 10; done
主机名和睡眠时间根据需要进行调整.在某些情况下,我在循环中链接两个或更多ntpq命令行.这样做时,我使用echo和/或date命令来指示数据集的更改位置.
