Re: 2.6.14-rc4-rt7

[George Anzinger]

George Anzinger wrote:
> Ingo Molnar wrote:
>
> > * George Anzinger <george@xxxxxxxxxx> wrote:
> >
> >
> > > The TSC is such a fast and, usually, accurate answer, I think it 
> > > deserves a little effort to save it.  With your new clock code I 
> > > think we could use per cpu TSC counters, read the full 64 bits and, 
> > > in real corner cases, even per cpu conversion "constants" and solve 
> > > this problem.
> >
> >
> >
> > the problem is, this is the same issue as 'boot-time TSC syncing', but 
> > in disguise: to get any 'per CPU TSC offset' you need to do exactly 
> > the same type of careful all-CPUs-dance to ensure that the TSCs were 
> > sampled at around the same moment in time!
> >
> > The box where i have these small TSC inconsistencies shows that it's 
> > the bootup synchronization of TSCs that failed to be 100% accurate. 
> > Even a 2 usecs error in synchronization can show up as a time-warp - 
> > regardless of whether we keep per-CPU TSC offsets or whether we clear 
> > these offsets back to 0. So it is not a solution to do another type of 
> > synchronization dance. The only solution is to fix the boot-time 
> > synchronization (where the hardware keeps TSCs synchronized all the 
> > time), or to switch TSCs off where this is not possible.
> I was rather thinking of only comparing a cup's TSC with the SAME cup's 
> TSC.  We only use the TSC to bridge from the latest update of the the 
> clock to now and when we update the clock we capture (i.e. update this 
> cup's last TSC value) the TSC on that CPU.  If we also capture the 
> system time then we have a set of (last TSC, sys clock) for each CPU.  
> If we further, keep 64-bits of TSC, we don't really require each cpu to 
> update the clock very often, or, we could force such and update from 
> time to time as needed.  This would not require the TSC to be synced at 
> all and even if they had different rates we could add that to the per 
> cpu data and cover that too.

Well fooie!  Still have to get them all in sync.  So this does not solve the problem.
> What this does require is that we do a really good job of figuring the 
> TSC multiplier, something we don't do at all well today (rc5-rt5 on my 
> box is fast by ~15 sec/ day).  We might also want to verify that we are 
> not letting monotonic time be other than monotonic :)
>
> As you might suspect, I have some ideas about how to do a much better 
> job of figuring out the TSC multiplier.

--
George Anzinger   george@xxxxxxxxxx
HRT (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/