是否有一个现有的机制，可以在线同步一个linux系统与NTP，并且在离线状态下可预测漂移RTC？
我们操作远程“收集器”：收集传感器数据并对其进行时间标记的embedded式Linux系统。 我们需要他们的时钟错误保持合理的小，比如5秒以内。 通常我们使用NTP来同步他们的时钟，并且工作正常 – 只要系统在线。
问题是一些collections家有非常糟糕的上行链路，可能会下降数小时，数天甚至数周。 这并不能阻止本地数据收集，但是如果没有NTP，Linux系统时钟会发生严重的漂移，并且相当不可预测。
OTOH，硬件的RTC漂移也很厉害，但速度不变。 RTC漂移率因板而异，但每块板不变，可以测量。
我想我们需要的是一个机制，做到以下几点：
对于“机制”，我的意思是一些维护良好，logging在案的软件和/或configuration可以处理“在线”与“离线”两种状态，确保系统时钟与正确的时间源同步（ntp vs. rtc），检测状态变化，并校正RTC漂移。 不pipe它是作为一个特殊的ntpdconfiguration/插件，作为单独的守护进程，还是作为一个cron作业来实现，都没关系。
我看了一下Chrony ，但是根据它的文档，它试图预测系统时钟的漂移，在我们的例子中漂移比RTC漂移更加不可预测。 Chrony似乎只使用RTC来保持重新启动的时间。
（1）注意ntpd激活内核的“11分钟模式”（每隔11分钟从系统时钟更新rtc）。 目前的内核和ntpd似乎没有办法阻止11分钟的模式。 因此，当ntpd正在运行（thx @billthor）时，任何rtc漂移信息都会丢失。
更新/编辑：
ntpdate(8) ， hwclock(8) ， date(1)等。请参阅斜体添加的部分关于我的意思是“机制”。 你的情况是不寻常的，如果有人想出一个标准的基于ntpd的configuration来做你想做的事，我会感到惊讶。 这就是说，我喜欢惊讶，而且这些部分经常发生。
但是，直到有人提出一个更好的主意，你有没有考虑过这样的crontab条目？
*/5 * * * * ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )
IE，每隔五分钟尝试通过ntpdate同步时钟，如果（并且只有）失败，根据/etc/adjtime文件调整硬件时钟漂移（其格式在man hwclock详细描述，其第一行你已经使用你对该特定RTC速率的知识进行了适当的填充），然后从RTC设置系统时钟。
请注意，如果您select这样的解决scheme，而且您正在部署大量这些系统，则使用该池时应认为是礼貌的，并根据您的使用情况提供相应的服务器。 您可以在http://www.pool.ntp.org/en/vendors.htmlfind更多信息。
NTP已经有了一些机制来知道它是在线还是离线，并且会根据需要切换到较低优先级的源。 检查到达值触发备用源是非常容易的，但我会坚持使用NTP。 如下面所讨论的，对RTC漂移的监测和校正可能是困难的。
在互联网前的日子里，我使用了一个可以打电话到数据源并同步时钟的程序。 仍然有可用的服务通过调制解调器提供时间源。 这将需要访问电话线。
本地时钟有已知的问题，不适用于RTC。 有些问题logging在NTP已知操作系统问题列表中。 这些可能会导致你的时钟漂移。 解决它们可以解决你的问题。 在没有错过蜱虫的情况下，我发现本地（系统）时间源可能非常稳定。
您可以使用Dumb时钟驱动程序（33），将程序写入相应的RTC时间到/ dev / dumbclockX设备。
还有一些基于无线电时钟的其他驱动程序。 其中一些使用诸如WWV和CHU之类的短波服务，这些服务可能在GPS信号不可用的环境中工作。 对于欧洲来说，这个清单将包括BBC，TDF，RBU和RMW。
Pavel Krejci也写了一个RTC驱动程序，但似乎并没有被纳入官方的驱动程序。 这可能与PPStypes同步一起工作。
应该可以在部署之前测量RTC漂移。 但是，您需要确保RTC没有被自动更新。 当使用adjtimex函数更新系统时钟时，RTC可能每11分钟更新一次。
NTP将在连接时更新时钟。 通常NTP将拒绝对系统时钟进行大的调整。 有选项可以调整时钟可以调整多远。
我build议使用上面的RTC的选项。 无线电时钟可能比GPS时钟更合适。
在没有可靠的时间源的情况下测量漂移以进行比较可能是徒劳的。 如果当地时间不稳定，则不能用它来监视RTC，反之亦然。 如果内核每隔11分钟更新一次RTC，则在连接NTP时测量漂移将不起作用。 我使用的RTC有一秒钟的分辨率，所以它们必须显着漂移才能可靠地测量。