我无法保证某些机器上的实时时钟是正常的（时间可能会有几小时、几个月甚至几年的误差）。由于我的网络也不稳定，所以我设置了 Chrony，希望它能解决这个问题。
但似乎 Chrony 想要随着时间的推移慢慢调整时钟，保持时钟单调，不发生剧烈变化。当漂移量达到秒级时，这已经足够了，但对于我的情况来说，这根本就不是一个解决方案（在我的测试中，花了几个小时才纠正了 10 分钟的漂移）。maxupdateskew顺便说一句，我禁用了。
我实际上想要的是启动时尽早进行重大更改（如果时间设置为未来，则为非单调的），精确到秒或（甚至更好）毫秒的量级，并且在应用后，ntp 客户端可以自由地进行逐步调整。我认为这是 ntp 客户端的一个重要用例，特别是对于没有 RTC 的机器，但我找不到针对此问题的良好支持解决方案。
我考虑了以下几点：
在 Chrony 执行其工作之前运行
hwclock --set --date="$(magically-get-correct-time)"; hwclock -s。问题是magically-get-correct-time仍然必须通过 ntp 或其他服务进行收集，然后我必须安排 Chrony 在它成功后运行。这很难做到（例如：如果此命令由于网络不佳而失败怎么办？这可能很快就会变得复杂）。总的来说，这感觉就像用胶带粘贴一样。在 Chrony 之前使用
ntpdate。Google 表示这在一些论坛中被建议。我不知道这效果如何，而且感觉像胶带一样。（此外，据报道 ntpdate 已被弃用）
现在，我实际上正在寻找一种仅使用 Chrony 来解决这个问题的方法。是什么让我想到可能可以通过 Fedora Wiki 上的相关页面解决Chrony 作为默认 NTP 客户端. 它声称：
初始同步后，时钟不再步进，这对于需要系统时间单调的应用程序非常有用
对我来说，这意味着在某种情况下初始同步，Chrony 可能会进行非单调步进。或者我希望如此。但在我的安装中，当它说
Feb 19 17:15:30 black chronyd[696]: System clock wrong by -759.702379 seconds, adjustment started
它没有跳到尽快积极纠正它；相反，它会将更改分散到几个小时，从不进行非单调更改。所以我没有看到任何提及的“初始同步”。而且我还没有找到如何配置它以使任何完全非单调调整。
顺便说一下，我正在运行带有 Chrony 1.27 的 Arch Linux