> On Wed, 8 May 1996, Ulrich Windl wrote:
>=20
> > 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=
my
[...]
> > > 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.
>=20
> 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=
pdate
> 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.
>=20
> > In Addidion as long as the RTC runs local time, you will have to ch=
ange
> > it when entering/leaving DST.
>=20
> The clock on Unix machines traditionally runs UTC. Setting the RTC to=
local
> time is just a hack to keep DOS users happy, not a high priority, IMH=
O...
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.
>=20
> > I think the RTC should be updated, even when the hardware is somewh=
at
> > broken: Setting the time shouldn't affect periodic interrupts.
>=20
> No it shouldn't, but if it _does_ make the interrupts unreliable, I'd=
say=20
> 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.
>=20
> --
> Johan Myreen
> jem@iki.fi
Ulrich