我们运营远程“收集器”：嵌入式Linux系统,用于收集传感器数据并对其进行时间戳.我们需要他们的时钟误差保持相当小,比如低于5秒.通常我们使用NTP来同步他们的时钟,并且只要系统在线,它就可以正常工作.
问题是一些收集器的上行链路非常糟糕,可能会持续数小时,数天甚至数周.这并没有阻止本地数据收集,但是如果没有NTP,Linux系统时钟会严重且无法预测地漂移.
OTOH,硬件的RTC也大量漂移,但速度不变. RTC漂移率因板而异,但每块板是恒定的并且可以测量.
我想我们需要的是一种执行以下操作的机制：
>在部署之前测量电路板的RTC漂移率
>尽可能通过NTP定期/定期调整系统时间
>当NTP不可用时,定期从RTC调整系统时间.考虑已知的RTC漂移率.
>可选：测量并记录在线时正在进行的RTC漂移率(1)
“机制”是指一些维护良好,文档化的软件和/或配置,可以处理“在线”与“离线”两种状态,确保系统时钟与正确的时间源同步(ntp vs. rtc),检测状态变化,并校正RTC漂移.它是作为一个特殊的ntpd配置/插件实现,作为一个单独的守护进程实现,作为一个cron作业,也无关紧要.
我看了Chrony,但根据其documentation,它试图预测系统时钟的漂移,在我们的情况下漂移比RTC更加不可预测. Chrony似乎只使用RTC来重新启动时间.
(1)注意ntpd激活内核的’11 -minute模式'(每11分钟从系统时钟更新rtc).目前的内核和ntpd似乎没有办法阻止11分钟的模式.因此,当ntpd运行时,任何rtc漂移信息都会丢失(thx @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 -minute模式’的脚注
> Here是关于离线同步和RTC漂移的非常有趣的讨论
解决方法
但是,直到有人提出更好的想法,您是否考虑过像这样的crontab条目？
*/5 * * * * ntpdate 0.pool.ntp.org || ( hwclock --adjust; hwclock --hctosys )
IE,每五分钟尝试通过ntpdate同步时钟,如果(并且仅当)失败,根据/ etc / adjtime文件调整硬件时钟漂移(其格式在man hwclock中详细说明,并且其第一行您已根据您对特定RTC速率的了解进行了适当填充),然后从RTC设置系统时钟.
请注意,如果您要使用这样的解决方案,并且要部署任意数量的这些系统,那么使用该池会被认为是礼貌的,并且会根据您的使用情况按比例提供服务器.您可以在http://www.pool.ntp.org/en/vendors.html找到更多信息.
