Re: [PATCH] x86: Export tsc related information in sysfs

[john stultz]

On Thu, May 20, 2010 at 12:19 PM, Brian Bloniarz <bmb@xxxxxxxxxxxx> wrote:
> 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
> reasons.

Yea, the relative instability of the tsc calibration at boot is an
issue for folks who want very very precise timekeeping immediately
after a reboot.

I proposed a solution to this awhile back via a boot option users
could use to specify the tsc_khz freq, so it would be consistent from
boot to boot. See: https://patchwork.kernel.org/patch/22492/

It didn't really go anywhere due to a lack of public interest.
However, if you're interested in playing with it, I can try to revive
the patch.

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