Re: Dual core Athlons and unsynced TSCs

[David Lang]

On Fri, 13 Jan 2006, Lee Revell wrote:

> On Fri, 2006-01-13 at 10:56 -0800, Sven-Thorsten Dietrich wrote:
> > On Fri, 2006-01-13 at 10:55 -0800, thockin@xxxxxxxxxx wrote:
> > > On Fri, Jan 13, 2006 at 01:09:51PM -0500, Lee Revell wrote:
> > > > > Some apps/users need higher resolution and lower overhead that only rdtsc
> > > > > can offer currently.
> > > >
> > > > But obviously if the TSC gives wildly inaccurate results, it cannot be
> > > > used no matter how low the overhead.
> > >
> > > unless we can re-sync the TSCs often enough that apps don't notice.
> >
> > You'd have to quantify that somehow, in terms of the max drift rate
> > (ppm), and the max resolution available (< tsc frequency).
> >
> > Either that, or track an offset, and use one TSC as truth, and update
> > the correction factor for the other TSCs as often as needed, maybe?
> >
> > This is kind of analogous to the "drift" NTP calculates against a
> > free-running oscillator.
> >
> > So you'd be pushing that functionality deeper into the OS-core.
> >
> > Dave Mills had that "hardpps" stuff in there for a while, it might be a
> > starting point.
> >
> > Just some thoughts for now...
>
> It kind of makes you wonder what in the heck AMD were thinking, whether
> they realized that this design decision would cause so many problems at
> the OS level (it's broken at least Linux and Solaris).  Maybe Windows
> keeps time in a way that was unaffected by this?

Lee, the last time I saw this discussion I thought it was identified that 
the multiple cores (or IIRC the multiple chips in a SMP motherboard) would 
only get out of sync when power management calls were made (hlt or 
switching the c-state). IIRC the workaround that was posted then was to 
just disable these in the kernel build.

if this is the case then I could easily see the hardware engineers 
thinking that if the software did a sleep thing then it was up to the 
software to re-sync the TSC clocks when the wakeup takes place.

David Lang

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

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