Bug 104888

I do NOT agree, I want to ajust the hwclock of my mainboard
to the correct system time. This because without there is no
control how big the drift of the mainboard clock is between
two reboots.

How (without ntp) can Linux possibly know better than the hwclock?
I seen the following scenario an various machines and SL versions:
(about) the first 5 sessions: no notable offset
next: 2 minutes off 
next: 5 min off
next: 10 min off
next: 20 min off   etc.
This is really bad.

Beside NTP it is possible to use e.g. the system time of the TV
channel or transponder configured in VDR or using the system time
of the ISDN provider like the Telekom.

Still, with no external time reference, never modify the hwclock.

Rudi?

I vote for disabling the drift compensation feature (/etc/adjtime) by default 
instead as that's what confuses people who don't know about it. Not syncing 
the system time to the hwclock at shutdown would mean changes like the ones 
done by vdr would be lost I guess. 

Args ... I hate recordings in the future.  I vote for the
drift compensation feature.

For people like you and me who know this feature exists and how it works it 
may be useful. However, it drives people nuts that sometimes set their time in 
Linux, sometimes in the BIOS and sometimes in Windows because they are unaware 
of /etc/adjtime. So what about introducing HWCLOCK_ADJTIME and HWCLOCK_SYSTOHC 
in /etc/sysconfig/clock? 

The hwclock setting is absolute required to to the fact that
if _no_ ntp is running the system clock is much more accurate
than the cmos.  The question which remains:  Why do jj
see an exponential increase of the offset, this looks like
an other bug.

IMHO this could be a kernel problem.

What magic is done by the system that it has a more accurate time
than a quartz clock?  Read: I don't believe it.

Hubert is on vacation. 
 
The cumulative time drift jj observed might be a case of lost timer ticks, 
but then the drift would be linear. 
The clock drift was backwards, not forward, right? 
 
Losing several minutes per session is bad though. Have you observed this 
behavior with SL10.0? If so, on what hardware? 

The drift is more often a forward drift (clock shows future).
The direction of the drift depends on the particular machine.
Observed on x86, amd64 and (intel) notebooks, all SL9.x.
Didn't try SL10 (as the problem only starts to show after,
say, 10 reboots within 2 weeks, there is little point in trying).

 

So it's not loss of timer ticks. 
 
If it goes in both directions, my suspicion would be that there's a systematic 
rounding error in the code that updates the adjtime file, and that simply 
accumulates as time goes by. 

Does not sound like a kernel bug to me.

does not sound like a ntp bug to me because jj isnt using ntp. And now?

Who is responsible for the boot.clock script?
Assign to him/her.

Btw. the script shouldn't say "setting up the CMOS clock"
when it really only sets the system time.

werner is responsible for the boot.clock script. i dont like bug ping pong

mmj: heard of any such problems with hwclock before ? 

Never

Me neither.

msommer (added to CC) has seen the bug, emap has seen it, I have
seen it.  You insinuate it does not exist?
It is not a ntp issue, CMOS clock should be left alone
when no (more reliable) timesource is used.
If you 'correct' the CMOS clock without ntp or equivalent
you will mess it up in almost all cases.
That simple.

ok back to werner then

Then your systems are broken. I've never ever seen that
with a correct configured system.

Not using UTC in CMOS toghether with a wrong configuration
within /etc/sysconfig/clock _is_ broken.  Assuming that the
system clock is less accurate than the CMOS clock is also
broken.  Not using the drift between system clock and
HW clock after a reboot is also broken.

I've systems with and NTP and all work as they  should.
Also the systems around here do their job. It was discussed
here and the current solution is correct.  This because
a simple reboot should not through the systen backward
in time.  This would cause many troubles like files put
into the future.

Why I can use "local time" in CMOS if it's not a good idea?
How can I have a wrong configuration in /etc/sysconfig/clock if I never touch
this settings?

I also have systems WITH NTP and all they work well. But the systems without NTP
don't work.

I have observed this behaviour myself on varous machines (workstations with
regular reboots) and a friend of mine reported the same problems to me. I think
it would really make sense to change this.

Or why not making this an option, which is disabled by default? So everyone
could be made happy here. I'd consider this a fine enhancement if you will.