Discussion:
[chrony-users] rtc is not being updated
Gernot Nusshall
2017-11-20 21:26:55 UTC
Permalink
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“.
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?

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

# 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:
root:~# adjtimex --print
mode: 0
offset: 0
frequency: -3562612
maxerror: 16000000
esterror: 16000000
status: 64
time_constant: 2
precision: 1
tolerance: 32768000
tick: 10000
raw time: 1511209389s 189560us = 1511209389.189560
return value = 5

# start uptime, local time, utc and rtc loop
root:~# while true; do echo '==='; date; uptime; timedatectl | egrep '(Local|Universal|RTC) time'; sleep 1m; done > time.log
https://pastebin.com/4m7qPFWE

# check 11-minute-kernel-mode:
root:~# adjtimex --print
mode: 0
offset: 0
frequency: 2965632
maxerror: 16000000
esterror: 16000000
status: 64
time_constant: 2
precision: 1
tolerance: 32768000
tick: 9999
raw time: 1511211108s 459113us = 1511211108.459113
return value = 5

# kernel config 'grep RTC config'
CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
# RTC interfaces
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
# I2C RTC drivers
# CONFIG_RTC_DRV_ABB5ZES3 is not set
# CONFIG_RTC_DRV_ABX80X is not set
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF85063 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8010 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
CONFIG_RTC_DRV_RV8803=y
# SPI RTC drivers
CONFIG_RTC_I2C_AND_SPI=y
# SPI and I2C RTC drivers
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set
# Platform RTC drivers
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1685_FAMILY is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_DS2404 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# on-CPU RTC drivers
# HID Sensor RTC drivers
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Bill Unruh
2017-11-20 21:37:43 UTC
Permalink
William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/
Post by Gernot Nusshall
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.
Post by Gernot Nusshall
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.
Post by Gernot Nusshall
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.
Post by Gernot Nusshall
# 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
Chrony purposely disables kernel 11 min mode because it completely negates the
whole effort chrony puts in to understanding the rtc.
Bill Unruh
2017-11-20 21:59:11 UTC
Permalink
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.
Post by Bill Unruh
Post by Gernot Nusshall
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.
Post by Gernot Nusshall
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.
Post by Gernot Nusshall
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.
Post by Gernot Nusshall
# 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
Chrony purposely disables kernel 11 min mode because it completely negates the
whole effort chrony puts in to understanding the rtc.
Gernot Nusshall
2017-11-20 22:16:51 UTC
Permalink
Thank you for your quick reply!
Post by Bill Unruh
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.
Post by Bill Unruh
Post by Bill Unruh
Post by Gernot Nusshall
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.
Post by Bill Unruh
Post by Bill Unruh
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.
Post by Gernot Nusshall
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).
Post by Bill Unruh
Post by Bill Unruh
Post by Gernot Nusshall
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 <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?
Post by Bill Unruh
Post by Bill Unruh
Post by Gernot Nusshall
# 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
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 <https://chrony.tuxfamily.org/doc/3.2/chrony.conf.html> ) is not functional anymore?
Bill Unruh
2017-11-20 23:00:16 UTC
Permalink
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.
Post by Gernot Nusshall
Thank you for your quick reply!
Post by Bill Unruh
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.
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?
Post by Gernot Nusshall
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.
Post by Gernot Nusshall
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
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?
Miroslav Lichvar
2017-11-21 06:39:32 UTC
Permalink
Post by Gernot Nusshall
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“.
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?
The adjtimex --print output shows STA_UNSYNC, but the strace output
shows that it is cleared later, so it should work as expected. It
might be a kernel issue. What kernel version and what architecture is
this?

Beside the CONFIG_RTC_SYSTOHC option there is also
CONFIG_GENERIC_CMOS_UPDATE, which I think is used on x86_64.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-***@chrony.tuxfamily.org
with "unsubscribe" in the subject.
For help email chrony-users-***@chrony.tuxfamily.org
with "help" in the subject.
Trouble? Email ***@chrony.tuxfamily.org.
Gernot Nusshall
2017-11-21 09:29:48 UTC
Permalink
Post by Miroslav Lichvar
Post by Gernot Nusshall
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“.
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?
The adjtimex --print output shows STA_UNSYNC, but the strace output
shows that it is cleared later, so it should work as expected. It
might be a kernel issue. What kernel version and what architecture is
this?
root:~# uname -a
Linux test 4.9.51 #19854 SMP PREEMPT Fri Nov 10 12:24:28 UTC 2017 x86_64 GNU/Linux

root:~# dpkg -l | grep chrony
ii chrony 3.0-4+deb9u1 amd64 Versatile implementation of the Network Time Protocol
Post by Miroslav Lichvar
Beside the CONFIG_RTC_SYSTOHC option there is also
CONFIG_GENERIC_CMOS_UPDATE, which I think is used on x86_64.
CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"
CONFIG_RTC_DRV_RV8803=y
# CONFIG_RTC_DRV_CMOS is not set

We have two rtc on our board and only one of them is battery backed. In order to work properly we had to disable the non-battery rtc with CONFIG_RTC_DRV_CMOS and enable the battery-backed rtc explicitly with CONFIG_RTC_DRV_RV8803=y

thank you!
Post by Miroslav Lichvar
--
Miroslav Lichvar
--
with "unsubscribe" in the subject.
with "help" in the subject.
Loading...