[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Real time clock too fast under OBSD



Marc Espie wrote:
> 
> On Sun, Feb 28, 1999 at 11:00:02PM +0100, WHS wrote:

...

> > >From the post by Marc Espie to tech ('Real-time clock and amiga port')
> > it seems OBSD reads the hardware clock (which itself runs perfectly
> > accurate) once, then updates it itself (don't know how) and then writes
> > it at shutdown (linux doesn't write it back btw). As the drift occurs
> > during running OBSD (tested with 'date' over a period of 4 hours, the 1
> > s per 5 m seems accurate), the problem seems to be the self update (the
> > same drift is also present under linux btw). Under linux, this isn't so
> > bad, as the clock doesn't get written at shutdown. It seems that that
> > should not be done anyway, or am I missing some important reason for
> > this? (I think it should just be written when the user manually adjusts
> > time or when using ntp).
> 
> If things were that simple...

...

> On the other hand, writing the kernel clock BACK to the hw clock at
> shutdown is a very important step. If linux doesn't do it, then linux is
> wrong. The point is, the files written to disks have dates attached to it.
> Whenever the machine starts up again, it may find itself in the future
> otherwise, with lots of unpleasant consequences.

So we must avoid files with mod. dates in the future.

Writing the clock back is not necessary, certainly not for a slow clock,
but also not for a fast one if one uses the following scheme:

shutdown:
	clock_dt = software_clock - hardware_clock;
	save (clock_dt);

boot:
	software_clock = hardware_clock;
	if (exists(saved_clock_dt)) {
		clock_dt = read_from (saved_clock_dt);
		if (clock_dt > 0) {
			software_clock += clock_dt;
			/* indicate to e.g. timeserver or an internal kernel time adjust
program
			 * that the clock must be slowed down until clock_dt is worked away
*/
		}
	}


Wouter