Clock stops ticking when inactive, causing drift

The clock applet drifts in time. Clock is set to "synchronize with internet ..." so it is correct at startup, but then if I stay inactive for some time, may be 5 min as well as 1 hour, the clock stops ticking. If I start to be active again, then the clock applet moves again, but the time is now late.

And it is not only the applet that is wrong, but the whole system date, because when I run date in a terminal, the time is also wrong.

Clarification : Sorry, may be my question was not clear. Here is my bug report to ubuntu :

Expected Behaviour :
Clock-applet displays the correct time,

Observed Behaviour :
Displayed time is drifting

How to reproduce :
If I get away from my computer for some times, the time displayed by the clock applet drifts. But the date command also show the wrong time. Moreover, sleep interval also get wrong. To debug this, I tested the following script :

#!/bin/bash
while [[ true ]]
do
    date >> clocktest.log
    hwclock >> clocktest.log
    sleep 300
done

Must be run as root because of hwclock. Il launched it :

./clocktest.sh &

and got away from my computer

Here is the output log :

1 mardi 17 août 2010, 12:42:12 (UTC+0200)
2 mar. 17 août 2010 12:42:13 CEST -0.346882 secondes
3 mardi 17 août 2010, 12:47:13 (UTC+0200)
4 mar. 17 août 2010 12:57:13 CEST -0.080965 secondes
5 mardi 17 août 2010, 12:52:13 (UTC+0200)
6 mar. 17 août 2010 13:02:14 CEST -1.002776 secondes
7 mardi 17 août 2010, 12:57:18 (UTC+0200)
8 mar. 17 août 2010 13:07:18 CEST -0.063633 secondes
9 mardi 17 août 2010, 13:02:18 (UTC+0200)
10 mar. 17 août 2010 13:12:19 CEST -0.361501 secondes
11 mardi 17 août 2010, 13:07:19 (UTC+0200)
12 mar. 17 août 2010 13:17:20 CEST -0.987434 secondes

Line 1 and 2 show the first time through the loop.
Line 3 and 4 show the bug : while date (and sleep) thinks 5 minutes have elapsed, hwclock shows that 15 minutes have elapsed.

Line 5 to 12 shows normal behaviour, except now date is late by 10 minutes. Behaviour is normal because I was back at my desk using the computer.

Having clock applet displaying the wrong time is one thing, but having the whole system time wrong (since sleep gets confused too) is a major bug.

Hardware : It is a fujitsu siemens amilo xi 2550 notebook. It was working fine with ubuntu 8.04

From ubuntu shodanex

• Your CMOS battery seems to be dying. Open the computer, and there's a little thing that looks like a large watch-battery on the motherboard. Replace that.

  garbagecollector : @maco its a battery its either dead or alive. maybe but its a long shot that this is the problem.

  msw : It is possible for a battery to be marginal, but the OP claim "so it is correct at startup" is (as yet) unsubstantiated and more information is needed to see if the "CMOS" RTC is bad or the soft system clock is weird. The distinction between the two is explained at http://tldp.org/HOWTO/Clock-2.html

  maco : I've had watch batteries drift when they were not-quite-dead. And I read correct at startup because of NTP to mean...well, that NTP was what's making it correct (ie, it's doing a sync at boot)

  shodanex : This has nothing to do with a dying cmos clock. cmos clock seems to be just fine
  From maco

• Are you perhaps running Ubuntu inside a virtual machine? If so, which brand?

  shodanex : no, see question for more info on the hardware
  From Dennis Kaarsemaker

• Hello shodanex, I'm experiencing the very same problem since last week.

  My Lucid (2.6.32-24-generic #41-Ubuntu SMP Thu Aug 19 01:12:52 UTC 2010 i686) runs on a fanless VIA desktop PC with OS's screensaver and power savings turned off completely except frequency scaling being set to "on demand". No VM is used.

  I used your script (extended by a line that also logs /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq ) to observe that the system time does not DRIFT (in relation to the CPU's clock maybe) but really STOPS approx. 8 minutes after I "left the desk". It continues to run at normal speed after I "returned" and keeps a fix offset then.

  For me, a high load (transcoding a video over night) did not keep the clock alive, I got an offset of 10 hours this way!

  Independent from the OS (it must be some BIOS setting), my screen goes blank after 15 minutes of input inactivity, but it goes instant on when I touch the mouse, and the applications are absolutely responsive (so no suspend to anywhere / hibernate).

  The gnome panel just reflects the system time, so the problem is in a deeper layer. I guess the new kernel just can't maintain the time correctly on hardware that does some unexpected power saving (laptops, fanless devices). Though my post does not provide a solution, you maybe don't feel so alone now :) Keep trying! Cellaz

  From cellaz