18

When certain time-related programs (like ntpd) are running on a Linux system, the kernel will switch into so-called "eleven minute mode" (see the hwclock man page) whereby it will automatically update the hardware clock from the system clock every eleven minutes.

On SLES11 I have empirically determined that if I set the hardware clock to be something like 10 hours behind the system clock, 11-minute mode seems incapable of making the hardware clock match the system clock. But if I set the hardware clock 5 minutes behind the system clock, 11-minute mode makes a perfect match.

So apparently there's some maximum update that 11-minute mode can handle and I'm wondering what it is.

Update:

This is weird...

More experimentation shows that when I have the HW clock around 20 minutes behind the system clock the 11-minute mode will set the HW clock to be exactly 30 minutes behind the system clock (!):

# date
Tue Dec  6 10:16:52 EST 2011
# hwclock --set --date "12/6/11 09:56"
#
# date
Tue Dec  6 10:17:16 EST 2011
# hwclock --show
Tue Dec  6 09:56:06 2011  -0.156551 seconds
#
# date
Tue Dec  6 10:23:09 EST 2011
# hwclock --show
Tue Dec  6 10:01:58 2011  -0.535772 seconds
#
# date
Tue Dec  6 10:34:28 EST 2011
# hwclock --show
Tue Dec  6 10:04:27 2011  -0.192025 seconds

Update:

I ran across this: https://bugs.archlinux.org/task/27408 which does imply that for good or bad the kernel will not update the hardware clock when the hardware clock time is too far off from the system clock time.

QuantumMechanic
  • 655
  • 6
  • 15
  • I have no idea what could be causing this, but I will ask the standard clock question: Is your hardware clock set to UTC? (If not it probably should be -- I don't think this accounts for the behavior you mention, but it could cause other strangeness...) – voretaq7 Dec 20 '11 at 16:48
  • Are you in India or setting your clock to Indian Standard Time? ITS is GMT +05:30 so that might account for a 30 minute offset. Also (but unlikely), a badly configured ntp server in India might be the cause. – Justin Dearing Dec 20 '11 at 19:21
  • Nope. I'm in US/Eastern and and NTP server is in our office and is also US/Eastern. – QuantumMechanic Dec 21 '11 at 17:19
  • Is this on a VPS? NTP and virtual environments don't play well together. – Scrivener Jan 11 '12 at 04:42
  • I couldn't find any reference information on 11-minute mode in the kernel and what limitations it might have. However, ntpd does check that the system time and the ntp server time are within 1000 seconds. If not, it won't even try to correct the system time. It thinks it might be that far off on purpose. Can you think of some way to verify that this kernel mode is limiting you rather than ntpd? – JakePaulus Jan 18 '12 at 16:46
  • @JakePaulus Depends on how you configure ntpd. – Karlson Jan 18 '12 at 17:01
  • As I just commented on Zouppen's answer, the `ntpd` on this machine was already being run with `-g`. – QuantumMechanic Jan 19 '12 at 18:16

3 Answers3

5

From the hwclock man page on RHEL 4.6:

This mode (we'll call it "11 minute mode") is off until something turns it on.  The ntp
daemon  xntpd  is  one thing  that  turns  it on.  You can turn it off by running
anything, including hwclock --hctosys, that sets the System Time the old fashioned way.

To see if it is on or off, use the command adjtimex --print and look at the value of
"status".  If the "64" bit of this number (expressed in binary) equal to 0, 11 minute mode 
is on.  Otherwise, it is off.

So by the virtue of you running hwclock --set you have likely turned it off. By the same token you can check the output of the adjtimex --print to confirm.

Karlson
  • 241
  • 3
  • 6
  • What turns it off is something that sets the **system time**. `hwclock --set` doesn't touch the system time. And when I do `adjtimex --print` that confirms that 11-min mode in **on** since the "64" bit is indeed off. – QuantumMechanic Mar 27 '12 at 16:53
  • *"If the "64" bit of this number (expressed in binary) equal to 0, 11 minute mode is on."* -- does it mean that if the status is odd then 11 minute mode is off (assuming status is 64-bit and big-endian bit order)? – jfs Jun 05 '15 at 13:20
  • If the "64" bit of this number (expressed in binary) equal to 0 ---> I see this as meaning the 7th bit, or `if((status & (1<<6)) == 0)` then 11 minute mode is on. – BMiner Mar 07 '16 at 20:54
  • There is implementation of 11 minute mode: http://lxr.free-electrons.com/source/kernel/time/ntp.c?v=4.4#L509 `sync_cmos_clock` function – osgx Jan 26 '17 at 15:37
4

In fact this has nothing to do with eleven-minute-mode in kernel. This is related to a feature in ntpd.

Are you aware of so-called sanity limit of ntp? If the time is too far away (for example 10 hours) ntpd gives up and doesn't skew the clock. In those cases, ntpd or ntpdate should be run manually. Ntpd option of -g should do that. Check information from the man page:

http://doc.ntp.org/4.1.0/ntpd.htm

Zouppen
  • 111
  • 5
0

Kernel will not sync the time if it's off more than 60 minutes when in Eleven Minute mode. This is a common problem in SUSE Enterprise, see this article from Open SUSE for some more details: https://lists.opensuse.org/opensuse-bugs/2011-06/msg01348.html

JasonV
  • 1