Bug 64178 - Systematic clock error
Systematic clock error
Status: CLOSED CURRENTRELEASE
Product: Red Hat Raw Hide
Classification: Retired
Component: kernel (Show other bugs)
1.0
alpha Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Copeland
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-27 18:37 EDT by Michal Jaegermann
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-30 17:53:36 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)
A patch to make frequency estimates tighter (5.53 KB, patch)
2002-04-30 12:27 EDT, Michal Jaegermann
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2002-04-27 18:37:32 EDT
Description of Problem:

Alpha kernels, including 2.4.9-31.1 from rawhide but not limited to that,
exhibit a systematic significant clock drift if left without synchronization
with an outside source.  On 800 MHz machine a system clock is around 15 seconds
per hour late.  This is 6 minutes per day.

To add insult to injury Red Hat scripts on a reboot clobber perfectly valid
hardware clock value (Alphas usually have much more stable hardware clock
than x86 boards) with a messed up system clock.

In absence of a good xntp server a workaround is to reset a system clock from
a hardware clock in a cron job.  Then time keeping is pretty good bug "jumpy".
Comment 1 Michal Jaegermann 2002-04-30 12:25:41 EDT
After dropping tolerances in arch/alpha/time.c from 1% to .1%  I can see now
while booting "HWRPB cycle frequency bogus.  Estimated 796284726 Hz".  This
is still not perfect, as either this frequency is underestimated or time
calculations are loosing precision,  but much better then the current state.
So far I am seeing a gain of something like 36 seconds, or maybe a bit less,
for 19 hours, i.e. an error of an order of 0.05%.  Moreover now this should
be also tuneable with 'cycle=...' boot parameter which was impossible before
(I did not try that yet).

I also "backported" changes in time.c from 2.4.19pre... to 2.4.9-... as
they make much more sense but tolerance limits are here really important.
One percent is nearly fifteen minutes per day.  A patch is attached.
Comment 2 Michal Jaegermann 2002-04-30 12:27:27 EDT
Created attachment 55884 [details]
A patch to make frequency estimates tighter
Comment 3 Phil Copeland 2002-04-30 17:53:31 EDT
I've changed the cpu_hz[] table entries for EV4 and LCA4 to have a low bound of
100MHz.

There were some TurboChannel machines (Pelica at least) with freq less than
150MHz

Phil
=--=
Comment 4 Phil Copeland 2002-08-12 15:08:23 EDT
Current release (RH 7.2 Alpha)

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