Re: Why touch the CMOS clock?

Ulrich Windl (
Wed, 8 May 1996 15:17:33 +0200

On 8 May 96 at 15:13, Johan Myr=E9en wrote:

> On Wed, 8 May 1996, Ulrich Windl wrote:
> > On 6 May 96 at 14:21, Johan Myr=E9en wrote:
> >=20
> > > My question is: Why does the kernel have to update the RTC? It is=
> > > approximation of the real time of day when the machine is power-c=
ycled? You
> > > can't trust the RTC anyway if the machine is down for a longer pe=
riod of
> > > time.
> >=20
> > The RTC usually is more precise than the interrupt driven clock.
> True. But the CMOS clock isn't used for timekeeping in the kernel. It=
is only
> read at boot time to initialize the system time. The only reason to u=
> the CMOS clock periodically is so it can be used more accurately to
> initialize the system time at the next boot. Setting the CMOS clock i=
s not
> essential in synchronizing the system time with an external source.
> > In Addidion as long as the RTC runs local time, you will have to ch=
> > it when entering/leaving DST.
> The clock on Unix machines traditionally runs UTC. Setting the RTC to=
> time is just a hack to keep DOS users happy, not a high priority, IMH=

As long as most PC systems (DOS, OS/2, Win95) use RTC with local time, =
I'll have to do=20
that in Linux, too.

> > I think the RTC should be updated, even when the hardware is somewh=
> > broken: Setting the time shouldn't affect periodic interrupts.
> No it shouldn't, but if it _does_ make the interrupts unreliable, I'd=
> the CMOS clock updating code should be removed.

The easiest fix is not using NTP. Clock not synchronized --> Not RTC=20
updates. Can't we add a CONFIG variable or some ioctl, or something=20
like that.

BTW: I had synchronized a PC's clock for many days, even during=20
transition to DST, but after reboot the time was off by one hour.=20
I've reported that problem once, but it has not been fixed yet. Maybe=20
I'll try to make a patch.

> --
> Johan Myreen