Re: [chrony-users] Getting time synchronization offset from chronyd

[Guy Morand <g.morand@xxxxxxxx>]

Hi Bill!

Thanks for reviewing my config and your precious advice!

> 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.

I only need to know that the system is not too much away from the
actual time (<= 1 second). I use *iburst* so that it gets quickly
synchronized at startup. I don't need much precision, that is why I
use big sync intervals. We are using the GSM network, where every MB
costs, I know NTP is not much but there is no small economy.

> 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.

I'm working on an embedded system that never gets correctly powered
off where I would normally sync the RTC during the shutdown procedure.

> The time is "corrected" every millisec by the rate correction, and certainle
> every minpoll (2^minpoll sec) and your logs would be swamped.

I guess you're right but this is probably a definition problem. With
"time correction" I meant when chrony measures the time difference
with our NTP servers, that is the "event" I need.

I hope this makes sense and my vision is not flawed :D!

BTW Mirsolav, I did some quick tests using your proposal and it seems
I was right, during startup I missed the most important gap and using
your approach with "named pipe log tracking"  would work, great!

Best regards,

Guy


On Wed, Jul 15, 2020 at 5:12 PM Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
>
>
> 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.
>

-- 
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.