Re: [chrony-users] rtc is not being updated

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

Note that for its purpose, the disciplining of the rtc is not terribly good.
One problem is that the temperature of the rtc is very different (10s of
degrees C) when the computer is off than when it is on, changing the rate of
the rtc oscillator (which is usually not terribly good). Secondly the rate
tends to get determined in the same way as the rate of the system clock-- ie
over a relatively short period of time ( 20 or thirty poll intervals-- poll
intervals could be as short as 16 sec for a refclock) On my systems the
refclock rate determination can jump around by over 1PPM.
The other problem is that some/many distributions will run hwclock to sync the
rtc and the system clock on shutdown. That of course completely destroys all
of the effort of chrony. Now, on some modern versions of hwclock, it will
calculate the drift of the rtc by subtracting the final offset between the rtc
and the sysem clock and dividing by the time between bootup and shutdown.
Unfortunately that causes problems when you run ntpd or chrony because that
initial offest is not really 0. 
Ie, the handling of the rtc and its drift and offset still does not really
have a decent solution, but the 11 min mode is probably the worst of all
possible solutions.

On Mon, 20 Nov 2017, Bill Unruh wrote:

> On Mon, 20 Nov 2017, Gernot Nusshall wrote:
>
> > Hi,
> >
> > i am not sure if i am experiencing a problem with chrony or the linux 
> > kernel.
> > I want the rtc to be updated with the 11-minute-mode of the linux kernel 
> > initiated with the chrony option „rtcsync“.
>
> Why would you want to do that? That is a much worse way of disciplining the
> rtc than almost anything else. It goes back to the early days of computers
> before ntp where the system clock would be updated by getting time from
> somewhere and just resetting the system clock to that time.
>
> chrony disciplines the rtc just as it disciplines the system clock. It
> measures the drift rate of the rtc and the offset of the rtc. Then when it is
> started it reads the old offset, the old drift rate, and corrects the rtc by
> those amounts. Now this is not idea, since the drift rate of the rtc when the
> computer is cold is probably different than what it is when it is operating
> and warm, but it is lot better than just jumping the rtc every 11 min. Ie, 
> you
> are trying to work against chrony which is incomprehensible.
>
>
> > I was expecting that the rtc is getting updated because the adjtimex output 
> > set by chrony seems correct and the kernel config options are also set 
> > correctly,
> > is there anything that i am missing?
>
> Yes. and understanding of how chrony works.
>
> > thanks in advance,
> > Gernot
> >
> > # set hwclock to something not equal local time/utc
> > root:~# hwclock --set --date 00:03:09
> > root:~# reboot
> > root:~# systemctl stop chronyd
>
> Agagagagarhehgh. Please understand how chrony works. By putting in that jump
> into the rtc, all chrony's efforts to understand the rate and offset of your
> rtc have been negated. Ie, this is a silly test because it would not happen 
> in
> reality.
>
>
> > # check if rtcsync is enabled
> > root:~# cat /etc/chrony/chrony.conf
> > logdir /var/log/chrony
> > logbanner 32
> > logchange 0.5
> > noclientlog
> > log measurements
> > log statistics
> > log tracking
> > makestep 1.0 -1
> > acquisitionport 123
> > manual
> > rtcsync
> > server 192.168.253.1 maxpoll 10
> >
> > # start strace (start chronyd)
> > nohup strace -f -tt -o time.strace /usr/sbin/chronyd -u _chrony &
> > https://pastebin.com/g9aNHkzV
> >
> > # check 11-minute-kernel-mode:
>
> Chrony purposely disables kernel 11 min mode because it completely negates 
> the
> whole effort chrony puts in to understanding the rtc.