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, Jan 13, 2006 at 10:56:13AM -0800, Sven-Thorsten Dietrich wrote:
    > On Fri, 2006-01-13 at 10:55 -0800, thockin@hockin.org wrote:
    > > 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...

    There's some chatter here about a solution involving a lazy sync of TSCs
    to the HPET (or other) whenever an app calls rdtsc after a potentially
    unsyncing event.

    For example, 'hlt' will initiate C1 which may cause clock ramping (and TSC
    skew). We can trap rdtsc after a hlt and re-sync the TSCs to some truly
    monotonic source, like HPET.

    I don't have all the details, some problems remain, and the work is not
    quite done yet, but it looks promising.

    Even if we eventually get synced TSCs, it's too little too late.
    basically, anything in-kernel that uses rdtsc is bound to break, and any
    app that uses rdtsc had better be using CPU affinity.

    Tim
    -
    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 20:25    [W:3.904 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site