☰

ntpd 本身无法正确更新漂移

tag-icon • tag-icon ntpd
ntpd 本身无法正确更新漂移

我使用的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 。

相关内容