是否存在一种现有的机制，可以在在线时将 Linux 系统与 NTP 同步，并在离线时与可预测漂移的 RTC 同步？
我们操作远程“收集器”：嵌入式 Linux 系统，用于收集传感器数据并为其添加时间戳。我们需要它们的时钟误差保持在合理的小范围内，比如说低于 5 秒。通常我们使用 NTP 来同步它们的时钟，只要系统在线，这种方法就没问题。
问题在于，有些收集器的上行链路非常差，可能会中断数小时、数天甚至数周。这不会停止本地数据收集，但如果没有 NTP，Linux 系统时钟会严重漂移，而且非常难以预测。
另一方面，硬件的 RTC 也会严重漂移，但漂移速率是恒定的。RTC 漂移速率因电路板而异，但每个电路板都是恒定的，并且可以测量。
我想我们需要的是一种能够执行以下操作的机制：
- 在部署之前测量电路板的 RTC 漂移率
- 尽可能通过 NTP 持续/定期调整系统时间
- 当 NTP 不可用时，定期从 RTC 调整系统时间。考虑已知的 RTC 漂移率。
- 可选：测量并记录在线时持续的 RTC 漂移率 (1)
我所说的“机制”是指一些维护良好、有文档记录的软件和/或配置，可以处理“在线”与“离线”两种状态，确保系统时钟与正确的时间源（ntp 与 rtc）同步，检测状态变化，并纠正 RTC 漂移。无论它是作为特殊的 ntpd 配置/插件、单独的守护进程、cron 作业还是其他方式实现的，都并不重要。
我看了克罗尼，但根据其文档它试图预测系统时钟，在我们的案例中，它的漂移比 RTC 更加难以预测。Chrony 似乎只在重启后使用 RTC 来计时。
(1) 注意 ntpd 激活内核的“11 分钟模式”（每 11 分钟从系统时钟更新一次 rtc）。当前内核和 ntpd 似乎没有办法阻止 11 分钟模式。因此，ntpd 运行时，任何 rtc 漂移信息都会丢失（感谢 @billthor）。
更新/编辑：
- 我们正在考虑通过 USB 或串行为 MSF 或 DCF77 信号（我们位于欧洲）添加外部无线电时钟。但我们宁愿保持硬件精简。
- 我们的收集器位于室内，通常位于地下室。因此添加 GPS 时钟不会有帮助。
- 我们使用 Debian 7。这意味着 hwclock 来自 util-linux-2.20.1，ntpdate-4.2.6p5，ntpd 来自 ntp-4.2.6.p5，chrony-1.24（可能是 1.30）。
- 请注意，我们的问题不是我们不知道如何使用、、
ntpdate(8)等。请参阅hwclock(8)date(1)斜体关于我所说的‘机制’。 - 添加了关于“11 分钟模式”的脚注
- 这里关于离线同步和 RTC 漂移的一个非常有趣的讨论
答案1
你的情况很不寻常，如果有人能提出一个基于标准ntpd的配置来做你想做的事情，我会感到惊讶。话虽如此，我喜欢惊喜，而且这种情况在这些地方经常发生。
但是，直到有人提出更好的主意为止，您是否考虑过crontab这样的条目？
*/5 * * * * ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )
即每五分钟尝试通过同步时钟ntpdate，如果（且仅当）同步失败，则根据文件/etc/adjtime（其格式在中详细说明man hwclock，并且您已使用对特定 RTC 速率的了解适当地填充了其第一行）调整硬件时钟的漂移，然后从 RTC 设置系统时钟。
请注意，如果您采用这样的解决方案，并且部署了大量此类系统，则与池合作并根据您的使用量贡献服务器被认为是礼貌的做法。您可以在以下位置找到更多信息：http://www.pool.ntp.org/en/vendors.html。
答案2
将其设置为使用伪时钟“本地时钟”。将其添加到 ntp.conf
server 127.127.1.1 iburst
fudge 127.127.1.1 stratum 8
服务器 127.127.1.1 是伪时钟，又称本地 RTC。iburst 可以快速与其同步（或不同步）。fudge stratum 8 将其从默认的 3 更改为更高的数字。应该高于您的其他服务器。
这将导致 ntpd 在与较低层服务器的连接丢失时使用本地时钟作为同步源，并在恢复连接时恢复到这些时钟。
答案3
NTP 已经具备了解其是否在线或离线的机制，并且会根据需要切换到优先级较低的源。检查到达值以触发备用源非常容易，但我还是会坚持使用 NTP。如下所述，监控和纠正 RTC 漂移可能很困难。
在互联网出现之前，我使用过一个程序，它可以通过电话连接到数据源并同步时钟。现在可能仍有一些服务可以通过调制解调器提供时间源。这需要使用电话线。
本地时钟存在一些已知问题，但这些问题与 RTC 无关。其中一些问题记录在NTP 已知操作系统问题。这些可能导致您的时钟漂移。解决它们可能会解决您的问题。在没有错过滴答的情况下，我发现本地（系统）时间源可能非常稳定。
您可能能够将 Dumb 时钟驱动程序 (33) 与将适当的 RTC 时间写入 /dev/dumbclockX 设备的程序一起使用。
还有许多其他基于无线电时钟的驱动程序。其中一些使用短波服务，如 WWV 和 CHU，这些服务可能在没有 GPS 信号的环境中工作。对于欧洲，此列表包括 BBC、TDF、RBU 和 RMW。
Pavel Krejci 也编写了一个 RTC 驱动程序，但它似乎没有被纳入官方驱动程序。这可能适用于 PPS 类型的同步。
在部署之前应该可以测量 RTC 漂移。但是，您需要确保 RTC 不会自动更新。当使用 adjtimex 函数更新系统时钟时，RTC 可能会每 11 分钟更新一次。
NTP 连接后会更新时钟。通常 NTP 不会对系统时钟进行大幅度调整。有选项可以调整时钟的调整幅度。
我已在上面推荐了使用 RTC 的选项。无线电时钟可能比 GPS 时钟更合适。
在没有可靠的时间源进行比较的情况下测量漂移可能是徒劳的。如果本地时间不稳定，您就无法使用它来监控 RTC，反之亦然。如果内核每 11 分钟更新一次 RTC，则在 NTP 连接时测量漂移将不起作用。我使用的 RTC 具有一秒的分辨率，因此它们必须发生显着漂移才能可靠地测量。