Re: process start time set wrongly at boot for kernel 2.6.9

[George Anzinger]

john stultz wrote:
~

> > > So rather then every tick incrementing jiffies, instead jiffies is set
> > > equal to (monotonic_clock()*HZ)/NSEC_PER_SEC. 
> >
> > As mention by me (a long time ago), this assumes you have a better source for 
> > the clock than the interrupt.  I would argue that on the x86 (which I admit is 
> > really deficient) the best long term clock is, in fact, the PIT interrupt.  The 
> > _best_ clock on the x86, IMHO, is one that used the PIT interrupt as the gold 
> > standard.  Then one smooths this to eliminate interrupt latency issues and lost 
> > ticks using the TSC.   The pm_timer is as good as the PIT but suffers from 
> > access time issues.
>
>
> Well, assuming the PIT is programmed to a value it can actually run at
> accurately, you might be right. 
>
> The only problem is I've started to arrive at the notion of
> interpolation between multiple problematic timesources is just a rats
> nest. When you can't trust timer interrupts to arrive and you can't
> trust the TSC to run at the right frequency, there's no way to figure
> out who's right.  We already have the lost-tick compensation code, but
> we still get time inconsistencies. Now maybe I'm just too dim witted to
> make it work, but the more I look at it, the more corner cases appear
> and the uglier the code gets. 
>
> I say pick a timesource you can trust on your machine and stick to it.
> NTP is there to correct for drift, so just use it.
Lets try to remember that the x86 WRT time is a real pile of used hay.  Even the 
"fixes" the hardware folks are spinning out reflect a real lack of 
understanding.  A pm_timer that you can not trust is doubly bad, but then they 
thought it was part of the powerdown code so...  The new timer which we may see 
on real machines some day, is still in I/O space (read REALLY SLOW TO ACCESS) 
for starters.

Back in my days at HP we (HP) talked with intel and, to some extent, caused a 
change in the IA64.  That machine, and a lot of other platforms, have decent 
time keeping hardware.  All we have to do is wait for the x86 to die :).
--
George Anzinger   george@xxxxxxxxxx
High-res-timers:  http://sourceforge.net/projects/high-res-timers/

-
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/