Re: boot time, process start time, and NOW time

[john stultz <johnstul@us.ibm.com>]

On Tue, 2004-08-17 at 10:41, Albert Cahalan wrote:
> On Tue, 2004-08-17 at 15:00, john stultz wrote:
> > What about 1001? That looks reasonably accurate.
> 
> Sure. (it's 10x worse, but the crystals aren't good
> enough to tell the difference) Supposing that a
> choice near 1000 HZ is good, here are some more:
> 
> wrongness_%   HZ_diff   PIT_#   HZ     actual_HZ   
> -0.00217900  -0.021703   1198   996   995.978297
> -0.00083809  -0.008389   1192  1001  1000.991611
> -0.00050285  -0.006376    941  1268  1267.993624
> +0.00050286  +0.005396   1112  1073  1073.005396
> +0.00150859  +0.014950   1204   991   991.014950
> 
> I think it's better to drop down a bit, because people
> have also been suffering problems with lost ticks.
> The BIOS can grab the CPU for too long.

Well, the move to HZ=1000 from HZ=100 was wanted to improve latency
requirements, so I don't know if folks would go for something like
HZ=519. The lost tick issue is a problem, but the real solution there is
to move the time subsystem away from depending on timer interrupts to
keep accurate time. See the proposal I just sent out for more details.
That way timer interrupts just become scheduler preemption points and
lost ticks become just an issue for folks with latency requirements. 

> I'd really rather just run everything off the RTC or HPET,
> with an arbitrary rate interrupt source, and just call into
> the regular jiffies handling code as needed to catch up.
> This would allow steering the jiffies tick to an exact
> integer HZ. High-precision timers could be fired off of
> the RTC or HPET interrupt if that is running faster.

Indeed, having alternate or multiple timer interrupt sources would be
nice. Hopefully once the time of day subsystem is untangled from the
timer subsystem, using alternate interrupt sources will be much easier
(and cleaner!). 

thanks
-john