Re: [chrony-users] Synchronize from precise RTC when offline or long tim

Rob Janssen wrote:

Jan Breuer wrote:

I also don't need terribly precise device. It is just for time attendance of employees. So ±1 minute is ok in offline/holdover.

So it is much better then system clock, which is >20ppm.

With this RTC I can reach ±1 min within 8 months. With system clock, it can go away 1 minute per month, which is not acceptable.

For a system like that, it is probably better to just run from the clock device you have (using its supplied driver) and use some cron job
to attempt an SNTP-type sync to a network clock on a regular basis (at boot and then once per hour, day, whatever).
When you get a valid network response you just "set" the system clock and the RTC without any slewing.

This is what am I doing now. I was just looking for something better and chrony is almost there.

E.g. doing monitoring is easy with chrony or ntpd. Chrony is also better in situation, where one server tells wrong time. I can't handle this correctly with SNTP-type sync.

That is what all those IoT devices are doing. No need to run a chronyd or ntpd type service that is syncing all the time.

The only advantage of doing that is that it would automatically determine the actual drift of the RTC device and when
no network sync is available it would extrapolate the RTC time using that predetermined drift, so you get more accurate time
after network loss, but that would actually backfire on you when in practice those devices are installed with temporary network access,
left to run only for a short while, and then disconnected from the network to run standalone forever. The drift calculated
over such a short interval would be quite wrong, and the result could be far worse than not applying a calculated drift at all.

My device is specific that it is connected all the time except some random network problems or it is always offline on some users.

So I could probably benefit from drift calculation..

Thank you,

Jan