在线时与NTP同步，脱机时与RTC同步？
是否有一种机制可以在联机时将linux系统与NTP同步，而在脱机时则与可预见的RTC同步？
我们操作远程“收集器”：用于收集和时间戳传感器数据的嵌入式Linux系统。我们需要他们的时钟错误保持合理的小，比如说低于5秒。通常我们使用NTP来同步他们的时钟，只要系统在线，就可以正常工作。
问题是，一些收藏家有非常糟糕的上行，可能会下降数小时，几天，甚至几周。这并不能阻止本地数据收集，但如果没有NTP，Linux系统时钟就会出现严重的、难以预测的漂移。
OTOH，硬件的RTC也有很大的漂移，但速度是恒定的。RTC漂移率因板而异，但每个板的漂移率是恒定的，可以测量。
我想我们需要一种机制来做以下工作：
- 在部署前测量板的RTC漂移率
- 在可能的情况下通过NTP调整系统时间
- 当NTP不可接受时，从RTC定期调整系统时间。考虑到已知的RTC漂移率。
- 可选:在线时测量和记录RTC漂移率(1)
我指的是一些维护良好、文档化的软件和/或配置，可以处理“联机”和“脱机”两种状态，确保系统时钟与正确的时间源(ntp和rtc)同步，检测状态变化，并纠正RTC漂移。无论它是作为一个特殊的ntpd配置/插件实现，还是作为一个单独的守护进程，作为cron作业，还是作为cron作业，都无关紧要。
我看了一下编年史，但根据它的文档，它试图预测系统时钟的漂移，在我们的例子中，系统时钟的漂移远比RTC更难以预测。Chrony似乎使用RTC只是为了在重新启动时保持时间。
(1) Note ntpd激活内核的“11分钟模式”(从系统时钟每11分钟更新一次rtc )。目前的内核和ntpd似乎无法阻止11分钟的模式。因此，在ntpd运行时，任何rtc漂移信息都会丢失(thx @billthor)。
更新/编辑：
- 我们正在考虑增加一个外部无线时钟为MSF或DCF77信号(我们在欧洲)通过USB或串行。但我们宁愿保持硬件的倾斜。
- 我们的收藏家都在室内，通常在地下室。所以增加GPS时钟是没有帮助的。
- 我们使用Debian 7，这意味着来自util-Linux2.20.1，ntpdate-4.2.6p5，ntpd来自ntp-4.2.6.p5，rony-1.24(潜在1.30)。
- 请注意，我们的问题并不是我们不知道如何使用
ntpdate(8)、hwclock(8)、date(1)等。请参阅添加的斜体部分，说明我的“机制”是什么意思。 - 添加了关于“11分钟模式”的脚注
- 这里是关于离线同步和RTC漂移的非常有趣的讨论。
回答 3
Server Fault用户
发布于 2014-10-23 15:52:30
您的情况是不寻常的，如果有人提出标准的ntpd-based配置来做您想做的事情，我会感到惊讶。尽管如此，我喜欢感到惊讶，而且这种情况经常发生在这些地方。
但是在有人想出更好的主意之前，你考虑过像这样的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上找到更多信息。
Server Fault用户
发布于 2020-06-20 08:58:30
将其设置为使用伪时钟“本地时钟”。将此添加到ntp.conf中
server 127.127.1.1 iburst
fudge 127.127.1.1 stratum 8服务器127.127.1.1是伪时钟，也就是本地RTC.快速同步到它(或不同步)。模糊层8将其从默认的3更改为更高的数字。应该比其他服务器高。
这将导致ntpd在失去与下层服务器的连接时使用本地时钟作为同步源，并在恢复连接时恢复到本地时钟。
Server Fault用户
发布于 2014-10-23 13:42:32
NTP已经有了知道它是在线还是离线的机制，并且它将根据需要切换到更低优先级的源。很容易检查reach值以触发另一个源，但我会坚持使用NTP。如下文所述，监测和纠正RTC漂移很可能是困难的。
在互联网前的日子里，我使用了一个程序，它可以打电话给数据源并同步时钟。可能仍有可用的服务通过调制解调器提供时间源。这将需要进入电话线。
关于本地时钟有一些已知的问题，不适用于RTC。NTP已知操作系统问题列表中记录了一些问题。这些可能解释了你的时钟漂移。解决这些问题可以解决你的问题。在没有漏掉滴答的情况下，我发现本地(系统)的时间来源可能非常稳定。
您可以通过一个将适当的RTC时间写入/dev/dumbclockX设备的程序来使用dev时钟驱动程序(33)。
根据无线电时钟，还有许多其他的司机。其中有些使用短波服务，如WWV和CHU，它们可能在没有GPS信号的环境中工作。在欧洲，这份名单将包括BBC、TDF、RBU和RMW。
Pavel也写了一个RTC司机，但它似乎并没有被纳入官方车手。这可能适用于PPS类型同步。
应该可以在部署之前测量RTC漂移。但是，您需要确保RTC不会被自动更新。当使用adjtimex函数更新系统时钟时，RTC可以每11分钟更新一次。
NTP将在时钟连接时更新它。通常，NTP将拒绝对系统时钟进行大幅度的调整。有一些选项可以调整时钟的调整范围。
我建议了使用上述RTC的选项。无线电时钟可能比GPS时钟更合适。
在没有可靠的时间源的情况下测量漂移与之比较可能是徒劳无功的。如果本地时间不稳定，则不能使用它来监视RTC，反之亦然。如果内核每11分钟更新一次RTC，则在NTP连接时测量漂移将无法工作。我所使用的RTCs只有一秒钟的分辨率，因此它们必须有显著的漂移才能可靠地测量。
https://serverfault.com/questions/639025
复制相似问题
腾讯云开发者
