[lkml]   [2009]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] tsc_khz= boot option to avoid TSC calibration variance
On 11 May 2009 at 19:12, john stultz wrote:

> All,
> Despite recent tweaking, TSC calibration variance is still biting users
> who care about keeping close sync with NTP servers over reboots.
> Here's a recent example:
> The problem is, each reboot, we have to calibrate the TSC, and any
> error, regardless of how small, in the calibrated freq has to be
> corrected for by NTP. Assuming the error is within 500ppm NTP can
> correct this, but until it finds the proper correction value for the new
> TSC freq, users may see time offsets from the NTP server.
> In my experience, its fairly easy to see 100khz variance from reboot to
> reboot with 2.6.30-rc.
> While I think its worth trying to improve the calibration further, there
> will likely be a trade-off between very accurate calibration and fast
> boot times.
> To mitigate this, I wanted to provide a tsc_khz= boot option. This would
> allow users to set the tsc_khz value at boot-up, assuming they are
> within 1Mhz of the calibrated value (to protect against bad values).
> Once the tsc_khz value is set in grub, the box will always boot with the
> same value, so the NTP drift value prior to reboot will still be correct
> after rebooting.


Hi everyone!

I was thinking a little bit on the issue, and I wondered (assuming the TSC
calibration and the hardware is somewhat stable) whether one should invent a
mechanism similar to the RTC or random pool; i.e. load the last value that was
stored or accumulated before. For the TSC calibaration one could build the average
of previous calibration values (if the value jumps between different numbers).
That would require a sysctl (or equivalent) interface however.


 \ /
  Last update: 2009-05-12 10:39    [W:0.048 / U:3.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site