[lkml]   [2010]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] x86: Export tsc related information in sysfs
    Ingo Molnar wrote:
    > The point is for the kernel to not be complicit in
    > practices that are technically not reliable.

    One usecase that hasn't been discussed is when userspace needs this info to
    calibrate the TSC.

    Take NTP as an example. It does a pretty good job of observing the drift in
    gettimeofday() against a reference clock and correcting for it. This seems
    to work well even when GTOD uses the TSC. But, it assumes that the drift
    changes slowly.

    That goes out the window on reboot, because the kernel only spends 25ms on
    TSC<->PIT calibration and the value of tsc_khz can vary a lot from boot to
    boot. Then NTP starts up and reads a drift value from /var/lib/ntp/ntp.drift
    that it *thinks* is accurate. In our experience, it'll then spend up to 48
    hours doing god knows what to the clock until it converges on the real
    drift at the new tsc_khz. initscripts could correct for the kernel's
    recalibration, but tsc_khz isn't exported.

    So it's too bad that it can't be exported somehow. The TSC on our
    machines has proven to be stable for all intents and purposes; I just
    checked 25 of my machines, most have uptime of >200 days, all of them
    still have current_clocksource=tsc. After NTP or PTPd has been running
    for a while, things converge, but being unable to reboot is a headache.
    Using the HPET for gettimeofday() would be impractical for performance

     \ /
      Last update: 2010-05-20 21:55    [W:0.019 / U:32.160 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site