![ntpd 本身无法正确更新漂移](https://linux22.com/image/191553/ntpd%20%E6%9C%AC%E8%BA%AB%E6%97%A0%E6%B3%95%E6%AD%A3%E7%A1%AE%E6%9B%B4%E6%96%B0%E6%BC%82%E7%A7%BB.png)
我使用的ntpsec
是 Debian不稳定版。在我的日志中我看到以下内容:
Mai 22 11:48:34 services ntpd[13428]: CLOCK: time stepped by 1.442261
Mai 22 11:55:06 services ntpd[13428]: CLOCK: time stepped by 1.524066
Mai 22 12:03:00 services ntpd[13428]: CLOCK: time stepped by 1.702944
Mai 22 12:08:34 services ntpd[13428]: CLOCK: time stepped by 1.517894
Mai 22 12:17:38 services ntpd[13428]: CLOCK: time stepped by 1.434055
Mai 22 12:24:07 services ntpd[13428]: CLOCK: time stepped by 1.084220
Mai 22 12:32:29 services ntpd[13428]: CLOCK: time stepped by 1.562280
Mai 22 12:38:38 services ntpd[13428]: CLOCK: time stepped by 1.211420
Mai 22 12:43:49 services ntpd[13428]: CLOCK: time stepped by 1.185642
Mai 22 12:48:58 services ntpd[13428]: CLOCK: time stepped by 0.796154
Mai 22 12:54:43 services ntpd[13428]: CLOCK: time stepped by 1.331323
Mai 22 13:00:21 services ntpd[13428]: CLOCK: time stepped by 0.849190
这不仅仅是今天,这样的情况持续了好几天。显然,ntpd
没有正确修复系统时钟漂移。里面/var/lib/ntpsec/ntp.drift
总是有:
500.000000
我现在尝试过的:
- 禁用CONFIG_RTC_SYSTOHC,因此内核不会自动更新RTC。几个小时后,我跑去
hwclock -w --update-drift
读取 RTC 时至少获得了更好的准确性。它将漂移系数设置为 0.78 秒/天。 - 之后,我跑去
adjtimexconfig
修复系统时钟(这是ntpd
应该做的事情)。它说:Comparing clocks (this will take 70 sec)...done. Adjusting system time by 275,531 sec/day to agree with CMOS clock...done.
结果似乎是ntpd
现在必须减少很多时间:
Mai 22 14:24:20 services ntpd[13428]: CLOCK: time stepped by 0.234963
Mai 22 14:30:30 services ntpd[13428]: CLOCK: time stepped by 0.145163
好的。但为什么ntpd
自己不这样做呢? 0.2秒/6分钟似乎仍然太不精确,所以我想我必须再重复这个过程几次。有什么建议么?
答案1
由于某种原因,您的操作系统时钟正在被非常不准确。通常ntpd
会通过以下方式保持正确的时间回转它,即告诉慢速时钟“加速”以使其赶上实时时间,只有在实际与实时同步时才调整时钟速度以匹配实时时间,并且同样减慢时钟如果太快了。
但对于您的操作系统时钟来说,这种调整似乎还不够:误差太大,ntpd
必须采取步进调整,本质上是每隔几分钟将系统时钟重置为正确的时间。如果你想对数据库等进行精确的计时,应该完全避免步骤调整。你应该不是对任何非零的步长调整感到满意。
幸运的是,误差似乎总是在同一方向,因此它可能是一个可以调整的系统误差。
笔记:如果这是虚拟机,则时间漂移可能是由于虚拟化主机在高负载下运行,并从空闲虚拟机“窃取时间”来运行繁忙的虚拟机而引起的。如果是这种情况,请首先咨询虚拟化主机管理员,了解修复计时的建议方法:可能有一个“半虚拟化时钟”选项,让虚拟机基本上使用主机的时钟进行计时,或者主机推荐的其他解决方案操作系统/管理程序供应商。如果您尝试使用 NTP 同步,只需确保虚拟化主机不会干扰虚拟机的时钟:只能是其中之一,而不是两者!
请注意,hwclock -w --update-drift
将通过将电池支持的 RTC 时钟与操作系统时钟进行比较来估计电池支持的 RTC 时钟的漂移,在您的情况下,已知操作系统时钟非常不准确。因此,您将调整一个可能好的时钟来匹配一个已知的坏时钟,这听起来不是一个好主意。
adjtimexconfig
另一方面,假设电池供电的 RTC 是正确的,并调整操作系统时钟的参数以匹配它。如果您有权访问已知良好的 NTP 时间源,则应使用adjtimex --host <NTP server>
直接将操作系统时钟与 NTP 服务器进行比较(ntpd
执行此操作时停止),然后使用adjtimex -p
查看结果frequency
和tick
值。
或者,您可以仅使用adjtimex -p
来查看frequency
已设置的偏移值ntpd
。ntpd
只会调整frequency
值;它tick
根本不会影响设置。
如果您发现频率偏移值已达到+/-32768000范围的任一端,则应tick
手动调整该值,然后重复该过程。
(如果frequency
达到或接近最大正值,则该工具正在尝试加快时钟速度,但由于超出了调整范围而无法足够快。要解决此问题,请增加该tick
值。如果frequency
达到或接近负值限制,减小tick
值。)
一旦找到一个tick
可以让频率偏移值保持在相对中间值附近的值(例如,+/- 5000000 左右),那么ntpd
通过根据需要调整频率偏移值,应该有更好的机会保持时钟同步。您应该手动编辑刻度值/etc/default/adjtimexconfig
并确保adjtimex.service
在启动时成功执行:它在启动之前运行,因此在开始充当它的“巡航控制”ntpd
之前将操作系统时钟设置为“正确的档位” 。ntpd
一旦您控制了操作系统时钟,那么它将ntpd
保持同步状态(ntpq -np
将在第一列中显示星号),并且除了启动时可能有一次之外,没有关于步骤调整的日志消息,那么您可以使用来hwclock -w --update-drift
估计RTC时钟的漂移率。最终的结果应该是一个系统,无论是否开机,都能保持尽可能合理的时间。
答案2
哦...也许adjtimexconfig
这就是答案?!不管是什么原因,我上面所做的最终对 ; 进行了ntpd
写入更新/var/lib/ntpsec/ntp.drift
;在过去 60 分钟内我只收到两条消息:
Mai 22 15:59:45 services ntpd[13428]: CLOCK: time stepped by 0.241656
Mai 22 16:31:47 services ntpd[13428]: CLOCK: time stepped by 0.532398
我想我现在对此很满意。
编辑:感谢 telcoM,我想我现在有了所有答案和解决方案。首先,解释一下发生的事情:10000 显然是初始的tick
。在我的系统上,这太慢了。所以ntpd
不得不不断地踩时间。ntp
不调整tick
,只做细粒度的调整,所以距离太远frequency
就有限,无能为力。tick
当我使用时adjtimexconfig
,它修复了tick
,但只是根据我也不准确的RTC。它设置tick
为 10031,这仍然明显太低,因此ntpd
仍然必须跳跃时间。这就是保持在 500.000000 的原因/var/lib/ntpsec/ntp.drift
(因此ntpd
似乎永远不会更新它),这相当于频率 32768000(漂移*65536)。
现在我曾经adjtimex -t 10038
修复过tick
,突然我再也看不到任何CLOCK: time stepped
消息了。ntpd
目前正在使用frequency: -10025033
,所以我想我也可以使用 10037 。