Red Hat Bugzilla – Bug 64178
Systematic clock error
Last modified: 2007-04-18 12:42:21 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".
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.
Created attachment 55884 [details]
A patch to make frequency estimates tighter
I've changed the cpu_hz table entries for EV4 and LCA4 to have a low bound of
There were some TurboChannel machines (Pelica at least) with freq less than
Current release (RH 7.2 Alpha)