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

[Albert Cahalan]

On Tue, 2004-08-17 at 15:00, john stultz wrote:
> On Mon, 2004-08-16 at 16:24, Albert Cahalan wrote:
> > On Mon, 2004-08-16 at 15:41, Andrew Morton wrote:
> > 
> > > Where did this all end up?  Complaints about
> > > wandering start times are persistent, and it'd
> > > be nice to get some fix in place...
> > 
> > If you're interested in reducing (not solving)
> > the problem for the 2.6.x series, you might change
> > HZ to something that works better with the PIT.
> > 
> > Here is a table showing % error for various HZ choices:
> > 
> > wrongness_%   HZ_diff   PIT_#   HZ     actual_HZ   
> > -0.00150855  -0.001509  11932   100    99.998491  
> > -0.00150855  -0.009474   1900   628   627.990526  
> > -0.00083809  -0.003051   3278   364   363.996949  
> > -0.00083809  -0.008389   1192  1001  1000.991611  
> > +0.00000000  +0.000000  14551    82    82.000000  
> > +0.00008381  +0.000304   3287   363   363.000304  
> > +0.00008381  +0.000435   2299   519   519.000435  
> > +0.00008381  +0.000525   1903   627   627.000525  
> > +0.01525566  +0.152557   1193  1000  1000.152557  
> > +0.01860917  +0.190558   1165  1024  1024.190558
> > 
> > As you can see, 1000 HZ and 1024 HZ are really bad.
> > They're worse than typical quartz crystal variation.
> > 
> > The old 100 HZ tick was just barely tolerable.
> > While 82 is perfect, it's a bit low. :-(
> > 
> > Some of the other choices are nice. How about 363,
> > 519, or 627?
> 
> 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.

We need to deal well with a few different frequencies:

100    the old clock tick
59.94  NTSC field rate
50     PAL field rate

The theory is that you need a frequency of just over 2x
the one you'd like, but in practice you need about 4x.
So that's why I suggested 363, 519, and 627.

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.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/