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.


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


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.

  • 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, 2011 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. Dec 20, 2011 at 19:21
  • Nope. I'm in US/Eastern and and NTP server is in our office and is also US/Eastern. Dec 21, 2011 at 17:19
  • Is this on a VPS? NTP and virtual environments don't play well together.
    – Scrivener
    Jan 11, 2012 at 4: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, 2012 at 16:46

3 Answers 3


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.

  • 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. Mar 27, 2012 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 5, 2015 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 7, 2016 at 20:54
  • There is implementation of 11 minute mode: lxr.free-electrons.com/source/kernel/time/ntp.c?v=4.4#L509 sync_cmos_clock function
    – osgx
    Jan 26, 2017 at 15:37

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:


  • 1
    On this machine ntpd is already being run with the -g option. Jan 19, 2012 at 18:15

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.