The Saturday 2003-11-22 at 22:19 -0500, Krikket wrote:
This is documented in the sdb and elsewhere.
Eh? Mind posting more info, or a link to it? I'm not sure what sdb is,
You should... SDB: SuSE Support knowledgebase It is on the SuSE web page, and also locally, at least up to SuSE 8.2. Search for CMOS or clock: * Rating (CPU) (19.06.2002) * iSeries: Time on the Linux partition is not correct (23.04.2002) * After booting the system clock is set wrong * Setting the clock to GMT (Greenwich Mean Time) -> * Your Computer Clock Shows the Wrong Time
or what you're getting at with the "two clocks" and all.
Every Personal Computer modeled after the IBM XT or AT since the eighthes has got two clocks :-) See "man hwclock", section "Clocks in a Linux System" for a good explanation of this. The subject has been talked about on this list several times. Just do a search for "keep time": |> Date: Fri, 18 Apr 2003 18:54:27 +0100 |> From: Keith Powell <keith@keithg4jvx.force9.co.uk> |> Reply-To: suse-linux-e@suse.com |> To: suse-linux-e@suse.com |> Subject: [SLE] SuSE8.2 won't keep time I copy from my own answers to that thread: CR> There are two clocks on any PC. One is the hardware or CMOS clock, CR> that runs from the battery when the computer is off. The other is the CR> system time, maintained by the CPU counting timer interrupts. The CR> system time is set up from the CMOS clock during boot up. CR> CR> Now, it is possible to know how much that clock drifts (all quartz CR> clocks are accurate, but have a constant error that can be CR> compensated). When the clock is adjusted, suse Linux is set up as to CR> save the amount of correction you added and do it for you next time CR> you boot (/etc/init.d/boot.clock): CR> CR> echo -n Setting up the CMOS clock CR> test -f /etc/adjtime || echo "0.0 0 0.0" > /etc/adjtime CR> /sbin/hwclock --adjust $HWCLOCK CR> rc_status CR> /sbin/hwclock --hctosys $HWCLOCK CR> CR> CR> Then, when the system is stopped, script "/etc/init.d/halt" does this: CR> CR> if test "$HWCLOCK_ACCESS" != "no" ; then CR> if rc_active xntpd ; then CR> echo -n "Set Hardware Clock to the current System Time" CR> # write back to hardware clock and calculate adjtime CR> /sbin/hwclock --systohc $HWCLOCK CR> rc_status -v -r CR> fi CR> fi CR> CR> CR> CR> Therefore, if you manually adjust the system clock, the relation CR> between system and hardware clocks are set out of balance, and the CR> automatic adjustment will in fact set it wrong. CR> CR> The correct procedure for setting up the time (not adjusting) would CR> be: CR> CR> 1) set the system time CR> 2) copy system to hardware clock (hwclock --systohc) CR> 3) Delete /etc/adjtime
I've been having a problem with the clock in KDE running slow -- as much as 10 minutes in a 30 minute period.
Compare the clock shown by KDE with the output from the command "date" on a console: they might be different, and if they are, it is kde who is wrong. Do this before doing any other change.
I don't understand why deleting the scripts to keep the clocks in synch would be a "good thing"...
Not certainly the script, but a data file used by the boot script (actually, bu hwclock) to know the amount the clock is going fast or slow. The boot script will recreate it. A paste from another of my posts: CR> No, I don't think is the hardware, nor the software: It is the user CR> ;-) CR> CR> It is explained somewhere on the suse SDB. What I understand is - more CR> or less -, that if you change, say, your system clock one hour fast CR> (but only system time, not hardware time) when the computer is halted, CR> the halt script notes the difference of one hour, and will save on the CR> adjustment file that the clock is slow by, say, one hour every day: so CR> the boot script will make the adjustment automatically when you boot CR> up. CR> CR> That is the idea, but of course, thinking that you want to compensate CR> seconds or minutes at the most, and that you had set it to the exact CR> time and seconds the first time. CR> CR> If you - we :-) - are not doing that, it is better that we delete the CR> adjustment file to disable the automatics, at least for this once. CR> CR> Then, if you use xntp or similar, or even the radio, the adjustment CR> will be made with exactitude, and the scripts will work as expected. Finally, if nothing of this helps, there are some chipsets that have known problems keeping time with Linux. Also, suspending the computer may throw the clock way off. -- Cheers, Carlos Robinson