lkml.org 
[lkml]   [2006]   [Jan]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Dual core Athlons and unsynced TSCs
    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@hockin.org 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@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: 2006-01-13 22:25    [W:2.306 / U:0.072 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site