Subject: Re: todr changes to improve clock accuracy across sleeps & reboots
To: Garrett D'Amore <email@example.com>
From: Perry E. Metzger <firstname.lastname@example.org>
Date: 09/08/2006 09:37:24
Garrett D'Amore <email@example.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.
> 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
> 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.