[chrony-users] Synchronize from precise RTC when offline or long time without synchronization

[Jan Breuer]

We have a device based on RaspberryPi running recent Raspbian Linux.
We are using TCXO based RTC which should keep time within ±3ppm (PCF2129).
We also expect that some devices will work completely without network all
the time so they will never see any NTP server.

I would like to have the most precise time on my device.
What I would like to do is to use RTC time in holdover (RTC->sys) and
synchronize RTC in normal operation (sys->RTC).
User will be able to manually set correct time in offline device if needed
so this should also propagate to RTC.

I know that rtcsync option will do the sys->RTC
I know that with refclock, I can implement SHM/SOCK driver which do
RTC->sys but this will prevent rtcsync on the same RTC.

Is there a possibility to realise this so I can have both RTC->sys and
sys->RTC depending on situation?

Jan Breuer

[Bill Unruh]

William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

We have a device based on RaspberryPi running recent Raspbian Linux. 
We are using TCXO based RTC which should keep time within ±3ppm (PCF2129).

3ppm is not terribly precise. That is 1 second in about 3 days. And if that is
your only timekeeper (source) it is all you are going to get.

We also expect that some devices will work completely without network all the time so they will never see any NTP
server.

Then you are going to have to get some other source for time.

I would like to have the most precise time on my device. 
What I would like to do is to use RTC time in holdover (RTC->sys) and synchronize RTC in normal operation
(sys->RTC).

But without an external source, your system could drift by much more than
3PPM.

User will be able to manually set correct time in offline device if needed so this should also propagate to RTC.

A user setting will be good to more than 1 second.

I know that rtcsync option will do the sys->RTC
I know that with refclock, I can implement SHM/SOCK driver which do RTC->sys but this will prevent rtcsync on the
same RTC.

You do not want rtcsync. That makes the rtc run at the same rate as the
system, which in general is worse than 3PPM if it is undisciplined.

There is the chronyc command trimrtc, but again it is only good to about a
second.

Without an external source of time, your clock is going to be out by many
seconds. You can get cheap gps receivers with pps which you can use on an
isolated system which will get you acuracy down to microseconds. Or
intermittent network connectivity.

Is there a possibility to realise this so I can have both RTC->sys and sys->RTC depending on situation?
Jan Breuer

[Jan Breuer]

Post by Bill Unruh
William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
We have a device based on RaspberryPi running recent Raspbian Linux.

Post by Jan Breuer
We are using TCXO based RTC which should keep time within ±3ppm (PCF2129).

3ppm is not terribly precise. That is 1 second in about 3 days. And if that is
your only timekeeper (source) it is all you are going to get.

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.

I just want to tell the chrony to beliave RTC more then system clock in
holdover.
So it will do opposite of trimrtc in holdover.

Post by Bill Unruh
We also expect that some devices will work completely without network all

Post by Jan Breuer
the time so they will never see any NTP
server.

Then you are going to have to get some other source for time.

Yes, the administrator of the device is that source (and his wristwatch).
No joke, that's my situation.

Post by Bill Unruh

Post by Jan Breuer
I would like to have the most precise time on my device.
What I would like to do is to use RTC time in holdover (RTC->sys) and
synchronize RTC in normal operation
(sys->RTC).

But without an external source, your system could drift by much more than
3PPM.
User will be able to manually set correct time in offline device if needed

Post by Jan Breuer
so this should also propagate to RTC.

A user setting will be good to more than 1 second.

Post by Jan Breuer
I know that rtcsync option will do the sys->RTC
I know that with refclock, I can implement SHM/SOCK driver which do
RTC->sys but this will prevent rtcsync on the
same RTC.

You do not want rtcsync. That makes the rtc run at the same rate as the
system, which in general is worse than 3PPM if it is undisciplined.

Thats it, I need chrony to conditionaly do rtcsync/trimrtc only in
situation it is synced from better source.
And do hctosys in situation, it is not synchronized.

Post by Bill Unruh
There is the chronyc command trimrtc, but again it is only good to about a
second.

Ok, trimrtc can be better then rtcsync for me.

Post by Bill Unruh
Without an external source of time, your clock is going to be out by many
seconds. You can get cheap gps receivers with pps which you can use on an
isolated system which will get you acuracy down to microseconds. Or
intermittent network connectivity.

This is everything OK for me. I know it will be going out, so the user will
be the only one who can correct it.
GPS is not a solution, because it can be inside a building and external
antenna is no go.

Post by Bill Unruh

Post by Jan Breuer
Is there a possibility to realise this so I can have both RTC->sys and
sys->RTC depending on situation?
Jan Breuer

Jan Breuer

[Rob Janssen]

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.

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.

Rob

[Jan Breuer]

Post by Jan Breuer
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.

Post by Jan Breuer
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