lkml.org 
[lkml]   [2004]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: boot time, process start time, and NOW time
From
Date
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site