Bug 64178

Summary: Systematic clock error
Product: [Retired] Red Hat Raw Hide Reporter: Michal Jaegermann <michal>
Component: kernelAssignee: Phil Copeland <copeland>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: alpha   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-04-30 21:53:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
A patch to make frequency estimates tighter none

Description Michal Jaegermann 2002-04-27 22:37:32 UTC 
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 16:25:41 UTC 
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 16:27:27 UTC 
Created attachment 55884 [details]
A patch to make frequency estimates tighter
Comment 3 Phil Copeland 2002-04-30 21:53:31 UTC 
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 19:08:23 UTC 
Current release (RH 7.2 Alpha)