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 100MHz. There were some TurboChannel machines (Pelica at least) with freq less than 150MHz Phil =--=
Current release (RH 7.2 Alpha)