我正在使用ntpsecDebian 不稳定版。在我的日志中，我看到了以下内容：
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
我现在尝试过的：
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 分钟似乎仍然太不准确了，所以我想我得再重复几次这个过程。有什么建议？
出于某种原因，您的操作系统时钟非常不准确。通常ntpd会通过回转来保持它在正确的时间，即告诉慢时钟“加速”以使其赶上实时，只有在实际与实时同步时才调整时钟的速度以匹配实时时间，如果太快，同样减慢时钟。
但是对于你的操作系统时钟来说，这种调整似乎还不够：误差太大，ntpd必须求助于步进调整，本质上是每隔几分钟就重置系统时钟以校正时间。如果您想对数据库等进行准确计时，则应完全避免步进调整。您不应该对任何非零量的步长调整感到满意。
幸运的是，误差似乎总是在同一个方向，所以它可能是一个可以调整的系统误差。
注意：如果这是一个虚拟机，时间漂移可能是由于虚拟主机在高负载下运行，从空闲虚拟机“窃取时间”运行繁忙的虚拟机造成的。如果是这种情况，请首先咨询虚拟化主机管理员以获取修复计时的推荐方法：可能有一个“半虚拟化时钟”选项，可以让 VM 实质上使用主机的时钟进行计时，或主机推荐的其他解决方案操作系统/管理程序供应商。如果您尝试使用 NTP 同步，只需确保虚拟主机不会摆弄 VM 的时钟：它是一个或另一个，而不是两者！
请注意，hwclock -w --update-drift将通过将电池支持的 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 时钟的漂移率。最终结果应该是一个系统，无论它是否通电，都能保持合理可达到的最佳时间。