Re: summary (Re: [patch] prefer TSC over PM Timer)

[George Anzinger]

john stultz wrote:
> On Wed, 2004-11-17 at 14:30 -0800, George Anzinger wrote:
>
> > The APIC timer is again on a different "rock" which is not designed for time 
> > keeping and, again, is calibrated at boot up against the "GOLD" standard PIT.
> >
> > IMHO, the best time keeping we can get in and x86 box is to:
> >
> > a) set up the PIT up to do the 1/HZ ticks (once set up we do not need to touch 
> > it again so the I/O access issues become mute),
> >
> > b) select either the TSC (if we think it is stable) or the pm_timer to do the 
> > short term between tick interpolation and also to detect and correct for PIT 
> > interrupt overrun (like we missed a tick or two).  We should prefer the TSC here 
> > because of speed and that it is read every gettimeofday() access.
>
>
> My only qualm here is that using the TSC to interpolate between timer
> ticks allows for time inconsistencies. If the TSC isn't cumulatively
> accurate, then when used in between ticks it will cause minor
> inaccuracies and possible inconsistencies. I'd instead prefer picking a
> single time source, and using NTP to correct for drift or inaccurate
> calibration. 

I think the inconstistancies are of the order of micro seconds and so will not 
really show.  Not all systems are connected to an NTP server.  One possibility 
is to build in an ntp like thing that averages out the PIT ticks and refines the 
TSC count per tick thing over a much longer period.  This would drive the errors 
way down into the noise and it still honors the notion of the PIT being the 
STANDARD for time.
> Also breaking time subsystem from requiring regular periodic ticks
> allows for tickless systems and additional power management savings. But
> this should be saved for another thread. 

Amen!
>

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