How to check if 11 minutes mode is syncing the hardware clock to the system clock?

Solution Verified - Updated

Environment

  • Red Hat Enterprise Linux 6.3+
  • Red Hat Enterprise Linux 7
  • Red Hat Enterprise Linux 8
  • ntpd
  • chrony

Issue

How to verify if 11 minutes mode is syncing the hardware clock to the system clock?

Resolution

RHEL8 or later, using chrony for syncing

  • In RHEL8, timedatectl can not be used to check 11 minutes mode is on and working or not.
  • Command timedatectl can not report the correct result. It shows "System clock synchronized: yes" even if "rtcsync" is commented in /etc/chrony.conf.

Please see here

RHEL7, using chrony for syncing

  • In RHEL7, use the ´timedatectl´ command to verify if the 11 minutes mode is on and working or not. 
[root@rhel7u9 ~]# timedatectl 
      Local time: Tue 2023-04-04 15:24:54 HKT
  Universal time: Tue 2023-04-04 07:24:54 UTC
        RTC time: Tue 2023-04-04 07:24:53
       Time zone: Asia/Hong_Kong (HKT, +0800)
     NTP enabled: yes
NTP synchronized: yes  <--------------
 RTC in local TZ: no
      DST active: n/a
  • If synchronized is yes, chronyd (ntpd) is in sync and 11 minutes mode is working.
  • If you disable "rtcsync" option in /etc/chrony.conf, synchronized will be no. so kernel discipline is disabled and 11 minutes mode would not work.
  • chrony basically works on slew mode. If chrony(or nptd) is working on slews mode, chrony(or ntpd) does not let kernel know if it is synchronized. However, chrony has "rtcsync" as a default option so that chrony can let the kernel know it is synchronized every 10 minutes.

RHEL7 and older, with ntp package

  • Use the ntptime command to verify if 11 minutes mode is on and working or not. 

    [root@dhcp2-62 ~]# ntptime 
ntp_gettime() returns code 5 (ERROR)
  time db39ef1c.a33d8000  Wed, Jul 20 2016 18:07:48.637, (.637657),
  maximum error 16000000 us, estimated error 16 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset 0.000 us, frequency 0.000 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 16 us,
  status 0x41 (PLL,UNSYNC), 
  time constant 7, precision 1.000 us, tolerance 500 ppm,
[root@dhcp2-62 ~]#

  • If UNSYNC is present in status, ntpd is not in sync and 11 minutes mode does not work.

  • If ntpd works as slew mode (with -x option), kernel discipline is disabled and 11 minutes mode would not work. Please see here about more details of "-x" option

  • If the step which is greater than 0.5 like "tinker step 1 ...." in ntp.conf is set up, kernel discipline is disabled and 11 minutes mode would not work. Please see 'man ntp_misc'

    Note: The kernel time discipline is disabled if the step threshold is set to zero or greater than 0.5 s and the threshold is applied also to leap second corrections.

  • If ntpd works as step mode and time between hardware clock and system time is close, ntpd will automatically sync system time to hardware clock in 11 minutes mode.

    [root@dhcp2-62 ~]# ntptime 
ntp_gettime() returns code 0 (OK)
  time db39f2df.91194798  Wed, Jul 20 2016 18:23:51.566, (.566792379),
  maximum error 8080726 us, estimated error 25 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 65.893 us, frequency -3.135 ppm, interval 1 s,
  maximum error 8080726 us, estimated error 25 us,
  status 0x2001 (PLL,NANO),  
  time constant 6, precision 0.001 us, tolerance 500 ppm,
[root@dhcp2-62 ~]#

  • If UNSYNC is not present in status, it is in sync.

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.