Bug 149649 - CMOS Clock drift calculations are not used
CMOS Clock drift calculations are not used
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: util-linux (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-24 15:33 EST by David Gardner
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-05 16:14:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Apply drift calculations to hwclock (5.38 KB, patch)
2005-03-06 07:45 EST, David Gardner
no flags Details | Diff
Apply drift calculations on running --hctosys (5.38 KB, patch)
2005-03-06 07:46 EST, David Gardner
no flags Details | Diff
New option to hwclock to tell it to keep old drift rate (5.49 KB, patch)
2005-03-06 07:50 EST, David Gardner
no flags Details | Diff
New option to hwclock to tell it to keep old drift rate (5.49 KB, patch)
2005-03-06 07:50 EST, David Gardner
no flags Details | Diff

  None (edit)
Description David Gardner 2005-02-24 15:33:02 EST
Description of problem:

In /etc/rc.d/rc.sysinit it seems to be assumed that either the cmos
clock is drift-free(!) or that /sbin/hwclock --hctosys adjusts for
drift. However, the command does not (at least now) adjust the time
from the cmos clock to account for drift.
The manpage for hwclock recommends calling /sbin/hwclock --adjust
before using --hctosys, presumably for exactly this reason,
however the command is called in /etc/rc.d/rc.sysinit before the 
root fs is remounted rw, so calling /sbin/hwclock --adjust 
there would either fail or would cause clock
corruption since the clock drift timestamp could not be written.

Solution 1 would be to patch hwclock to perform drift calculations
before setting the clock. Solution 2, which I assume is a lot easier,
would be to call /sbin/hwclock --adjust before setting the system 
time from the clock, which means it would have to
be done after remounting root. Not sure what this might break though.

Also, if ntpd is being run, then the drift calculations are rendered
useless by the final saving of system time in the shutdown script -
there would need to be some sort of cooperation between ntp and the
shutdown script to fix this though.

Version-Release number of selected component (if applicable):

Those in FC1.0 to 3.0, maybe earlier & later too. I think it used to
work properly in RH6.0, but maybe I'm misremembering.

How reproducible:
 100%!

Steps to Reproduce:
1. Have CMOS clock which drifts at a measurable rate.
Use adjtimex to find cmos clock drift rate, set in /etc/adjtime.
Set clock to right time.
2. Turn machine off for long enough to measure a second or 2 drift (2
days on my machine!). Boot.
3. 
$ hwclock ; date +%c%N
(clocks show almost identical, incorrect times)
$ hwclock --adjust.
$ hwclock ; date +%c%N
 Notice that hwclock now shows correct time.
  
Actual results:

Frustrated user after carefully setting drift rates and still finding
that the computer never tells the right time. - 5 mins our after 6
months. Used to be better than this!

Expected results:

With drift calcns used properly, system clock should only need
milisecond slews from occasional ntp queries once a month, not 5
second jumps after only a week.

Additional info:
Comment 1 Bill Nottingham 2005-02-24 17:15:02 EST
We don't want to move the hwclock invocation to later, as that causes
improper time and date stamps in logs, etc.
Comment 2 David Gardner 2005-02-25 15:19:54 EST
Not knowing much about the internals of the scripts, surely not much
is going to get logged anywhere before root is mounted RW? I thought
syslog applied the timestamps and that won't happen until way after
root remount.

Even if I'm wrong, I'd  rather a couple of early boot-log lines get
the wrong time than every log item wrong until the time gets corrected. 
Comment 3 David Gardner 2005-03-06 07:45:45 EST
Created attachment 111709 [details]
Apply drift calculations to hwclock

I don't at all see why hwclock should ever NOT apply drift caclulations
(assuming they are valid), so I've hacked it so it does. This almost certainly
adds an extra delay before setting the clock so I'd not expect perfect
accuracy, but I seriously doubt it'll ever be worse than not applying the drift
calculations at all. Hopefully I got the signs right...
Comment 4 David Gardner 2005-03-06 07:46:16 EST
Created attachment 111710 [details]
Apply drift calculations on running --hctosys

I don't at all see why hwclock should ever NOT apply drift caclulations
(assuming they are valid), so I've hacked it so it does. This almost certainly
adds an extra delay before setting the clock so I'd not expect perfect
accuracy, but I seriously doubt it'll ever be worse than not applying the drift
calculations at all. Hopefully I got the signs right...
Comment 5 David Gardner 2005-03-06 07:50:34 EST
Created attachment 111711 [details]
New option to hwclock to tell it to keep old drift rate

If ntpd has been run long enough to tell the kernel that it's clock externally
synchronised, then the cmos clock drift caclulations are by definition wrong. 
This patch lets, say, the ntpd or shutdown scripts record the return to an
unsyncronised state.
Comment 6 David Gardner 2005-03-06 07:50:45 EST
Created attachment 111712 [details]
New option to hwclock to tell it to keep old drift rate

If ntpd has been run long enough to tell the kernel that it's clock externally
synchronised, then the cmos clock drift caclulations are by definition wrong. 
This patch lets, say, the ntpd or shutdown scripts record the return to an
unsyncronised state.
Comment 7 Karel Zak 2005-09-30 11:22:02 EDT
Please, send your patch to upstream developers. I would like to see this
integrated by upstream rather then FC/RHEL specific patch. Thanks.
Comment 8 John Thacker 2006-05-05 16:14:43 EDT
Closing per previous comment.

Note You need to log in before you can comment on or make changes to this bug.