From: Ingo Molnar <mingo@elte.hu>
To: john stultz <johnstul@us.ibm.com>
Cc: George Spelvin <linux@horizon.com>,
ulrich.windl@rz.uni-regensburg.de, linux-kernel@vger.kernel.org,
tglx@linutronix.de, Clark Williams <williams@redhat.com>,
zippel@linux-m68k.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC][PATCH] tsc_khz= boot option to avoid TSC calibration variance
Date: Fri, 8 May 2009 14:15:21 +0200 [thread overview]
Message-ID: <20090508121521.GC18758@elte.hu> (raw)
In-Reply-To: <1241742647.7518.108.camel@localhost.localdomain>
* john stultz <johnstul@us.ibm.com> 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:
> http://lkml.indiana.edu/hypermail/linux/kernel/0905.0/02061.html
>
> 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.
>
> Thanks to George Spelvin for the idea:
> http://lkml.indiana.edu/hypermail/linux/kernel/0905.0/02807.html
>
> Thoughts or feedback?
>
> Signed-off-by: John Stultz <johnstul@us.ibm.com>
Wouldnt it be a lot more flexible to have a sysctl for this, which
would be set before ntpd is started? (or which would be set by ntpd)
The mechanism and semantics would be similar: we would _not_ expose
cpu_khz directly, we'd have a boot_cpu_khz value saved for sure, and
we'd allow the sysctl to set the cpu_khz to within 1MHz of cpu_khz -
and we'd re-scale the timer irq and other calibrated values
accordingly.
Alternatively, a much simpler method: why doesnt ntpd save its own
notion of cpu_khz once it has reached stability, and reads cpu_khz
(from /proc/cpuinfo) during bootup and re-scales its initial offset
and phase shift accordingly, compensating for that noise? (if it's
within 1MHz)
Ingo
next prev parent reply other threads:[~2009-05-08 12:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-08 0:30 [RFC][PATCH] tsc_khz= boot option to avoid TSC calibration variance john stultz
2009-05-08 12:15 ` Ingo Molnar [this message]
2009-05-08 15:12 ` George Spelvin
2009-05-08 19:06 ` [RFC][PATCH] tsc_khz= boot option to avoid TSC calibrationvariance john stultz
2009-05-08 12:19 ` [RFC][PATCH] tsc_khz= boot option to avoid TSC calibration variance George Spelvin
2009-05-08 15:27 ` George Spelvin
2009-05-08 19:02 ` john stultz
2009-05-11 6:54 ` George Spelvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090508121521.GC18758@elte.hu \
--to=mingo@elte.hu \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=ulrich.windl@rz.uni-regensburg.de \
--cc=williams@redhat.com \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox