| Re: [chrony-users] Getting time synchronization offset from chronyd |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Wed, 15 Jul 2020, Guy Morand wrote:
Hallo chrony users!
I'm developping an "IoT" device that sends events to a remote server. We
need to make sure that the timestamp is not too much away from the
actual time, that is why we use chrony to synchronize the time with our
servers and correct events that drifted too much after the first time
correction. The configuration looks like this:
```
pool <our_server> iburst minpoll 12 maxpoll 13
If you want to have your system track thetime properly, a minpoll of 12 is
not a good idea This means that your systen asks the server every 70min
(2^12=4096 sec) what
the time is. Since chrony needs at least 3 readings to do anything it will
take over 4 hours to do anything. I would suggest more like a minpoll of 4 (16
sec)
since this is your own network, any, unless you have a million clients or a
passenger pigeon network, it will be a minimal network traffic effect.
makestep 1.0 3
driftfile /var/lib/chrony/drift
logdir /var/log/chrony
rtcdevice /dev/rtc
rtconutc
rtcsync
Why do you do rtcsync? That syncs the rtc (Real time clock) to system clock
every 11 min which makes the chrony measurement of the rtc very hard
especially as the resetting of the rtc on many systems is really only good to
about a sec. It does not have an impact on your problem however.
```
What does that ellipses hide?
In another thread, I'm checking if the time was synchronized and how
much it was corrected by polling the chrony daemon with:
```
$ chronyc -n tracking
Reference ID : 9DE666BD (157.230.102.189)
Stratum : 3
Ref time (UTC) : Wed Jul 15 10:51:02 2020
System time : 0.000009834 seconds slow of NTP time
Last offset : +0.692694306 seconds
RMS offset : 0.692694306 seconds
Frequency : 166.138 ppm fast
Residual freq : +0.000 ppm
Skew : 12.204 ppm
Root delay : 0.028277593 seconds
Root dispersion : 0.036599152 seconds
Update interval : 4161.7 seconds
Leap status : Normal
```
I use *Leap status* to make sure that the time is in sync and *Last
offset* to read the time correction.
??
However, after changing the system time to few hours ago and rebooting,
I got a time correction of few milliseconds. My assumption is due to the
"iburst" parameter, the time got corrected more than once and missed the
biggest correction that was of few hours. Is that plausible?
Yes So many think that changing the system time and immediately seeing how
lon it takes to correct that is a good test. It is not. It takes a while --
in your case with your minpoll, days, for chrony to have enough data to get
the system time back on track. ntpd or chrony do NOT have infinite trust of
ther servers. They wait a while (many minpolls) to decide that there is
really something wrong and not simply some transient abberation. Reacting
immediately to any difference produces poor behavior of a time keeping
program and can lead to instabilities. The best test is to let it run for a
while (lets say 100 times minpoll-- in your case about 5 days-- to see how
accurate the system time is.
* Am I reading the right field?
* Is there a way to get events directly from the chrony daemon when a
time correction was done (UNIX socket) to not misse any time
correction?
The time is "corrected" every millisec by the rate correction, and certainle
every minpoll (2^minpoll sec) and your logs would be swamped.
* Is there a better approach to achieve this?
Thanks for the pointers!
Best regards,
Guy Morand
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.