Subject: Re: todr changes to improve clock accuracy across sleeps & reboots
To: Garrett D'Amore <garrett_damore@tadpole.com>
From: Perry E. Metzger <perry@piermont.com>
List: tech-kern
Date: 09/08/2006 09:37:24
Garrett D'Amore <garrett_damore@tadpole.com> writes:
> I agree that during settimeofday(2), we should use a callout to schedule
> it as closely to a second as possible.
>
> Shutdown, suspend, and startup are harder.  I suggest that we are
> over-engineering the problem.  A one second delay at each of these times
> is the _worst_ case scenario.  I would be very surprised if anyone
> noticed a one second delay at these times.

I tend to agree. Average case will be .5 seconds, which is acceptable.

> Furthermore, some clocks might actually support better time resolution
> than 1 second.  The todr calls can support up to microsecond resolution.

Yup.

> Frankly, overall system performance implications by additional code to
> do the scheduling, plus all the testing to make sure nothing is busted,
> pushes me even more strongly away from this.
>
> Therefore, my recommendation is to skip all this effort attempting to
> shave off that second, and spend it somewhere where the effort will
> contribute to run-time performance.

At the very least, I think we should start with something dead simple
and *only then* try something more complicated if it turns out to be
important.

> A better way to improve boot time and shutdown performance, IMO, is to
> figure out how to parallelize some things like startup scripts.  I
> suspect that a lot can be run in parallel that currently isn't. 
> (Solaris 10 and MacOS X I think each have demonstrated that.)

That would be quite straightforward, in fact, given that we already
have dependency chain checking in our RC system.

Perry