问系统时钟漂移过大？(每小时2+分钟)

EN

我正在一个新系统上运行一个合理的新安装17.10 (完全修补，而不是虚拟化)，并注意到/proc/stat's btime条目中列出的启动时间一直在变化。这破坏了一些脚本，这些脚本使用这些信息来计算启动某些进程的挂钟时间。

通过一些调试，我发现btime被计算为now() - uptime，而btime漂移是由于系统时钟以与正常运行时间时钟不同的速度递增的！

我认为这是由于systemd-timesyncd.service (即ntpd替换)应用于系统时钟的某种时钟循环造成的，因此我禁用了timesyncd并重新启动，作为测试。果然，现在正常运行时间计数器和系统时钟的步数是一样的。(我还安装了adjtimex来检查内核参数，以验证是否存在时钟延迟:不存在frequency偏差，tick值为10000，这是应该的。)

然而，如果没有timesyncd，很明显，系统时钟是非常不正常的。这个时钟在135分钟(~ -37000 ppm)的过程中损失了大约5分钟，这与我在大约20分钟内使用adjtimex -l -w手工估计系统时钟漂移的过程类似(它给出了-40000 ppm)。(事实上，为了检查一下，使用秒表，我发现/proc/uptime也在以错误的速度递增；~ -41000 ppm。所以这是一致的。)

CMOS时钟也有点偏离(它比135分钟增加了30秒)，但我的理解是，这不应该影响系统时钟，只有在启动时间。没有一个/etc/adjtime文件，我可以找到在启动时系统时钟速率将被改变-无论如何，正如上面的adjtimex报告，没有时钟滴答伪造。所以我无法想象CMOS时钟会如何引起我看到的系统时钟的问题。

尽管如此，我将更换CMOS电池，因为一些报告建议这可以奇迹般地解决系统时钟问题。(尽管没有明显的机制来实现这一目标。)

但是，对于为什么系统时钟会如此错误，还有其他解释吗？对于系统计时器数量如此庞大这一事实，有什么解决办法吗？显然，仅仅运行timesyncd并不能解决问题，因为它产生的过多时钟会产生问题(如上面所示)。

我可以使用adjtimex直接更改内核参数(这至少应该保持正常运行时间和系统时钟计数器的同步)，但这实际上是为了解决+- 500 ppm范围内的时钟错误。我看到的是3个数量级的大，我不知道它是否表明了一些更重要的问题。

作为记录，我在一台非常相似的机器上安装的17.10设备没有这个问题。

更新:改变CMOS电池没有任何作用(如怀疑)。问题的最终解决办法见下文。