| Re: [chrony-users] rtc is not being updated |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
It would be nice if your email software used > >> >>> etc to designate the
various levels of quoting. Indentation which is what is seems to use very
raplidly eats up space, and is really hard to follow.
On Mon, 20 Nov 2017, Gernot Nusshall wrote:
Thank you for your quick reply!
On 20.11.2017, at 22:59, Bill Unruh <unruh@xxxxxxxxxxxxxx> wrote:
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.
Ok, i understand!! For the sake of documentation and to explain my scenario a little bit i will also reply to your
first message.
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.
In my scenario i can not be sure that the ntp server is still reachable after a first initialisation and reboot of
the device. The rtc might be months or years off. Therefore i want to be sure that the rtc is not getting
disciplined but stepped after the system time is in sync and the system is getting rebooted. After your reply i
think a systemd.shutdown script with something like „hwclock -w“ will fit my needs better.
The rtc clock is not that bad. It tends to have a rate that is out by say 10s
of PPM. Lets say 20PPM. To get it off by a day would require hundreds of
years. And if your system has no outside source of time-- either ntp servers
or gps, it would be out by slightly less than that but still a lot, and if you
have no servers, or gps why are you running chrony?
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.
Well, i think i know the „basics“ and i thought that the rtcsync option would help me in my scenario (see above).
It will enable the 11 min mode, but as the doc says it disables the normal rtc
tracking. Ie, the "rate prediction" of the normal chrony mode is disabled, and
if the system goes off for a while, it cannot apply a rate correction to the
time given by the rtc.
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.
I found a similiar issue ( https://bugzilla.redhat.com/show_bug.cgi?id=985522 ;) and figured it would be an
appropriate test for my problem too. I am always willing to learn something, what would be a better test?
# 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.
Does that mean that the rtcsync option ( https://chrony.tuxfamily.org/doc/3.2/chrony.conf.html ;) is not functional
anymore?