From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757443Ab0EZUXF (ORCPT ); Wed, 26 May 2010 16:23:05 -0400 Received: from sprinkles.athenacr.com ([64.95.46.210]:32684 "EHLO sprinkles.inp.in.athenacr.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755184Ab0EZUXB (ORCPT ); Wed, 26 May 2010 16:23:01 -0400 Message-ID: <4BFD8322.3040905@athenacr.com> Date: Wed, 26 May 2010 16:22:58 -0400 From: Brian Bloniarz User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: john stultz CC: "H. Peter Anvin" , Dan Magenheimer , Ingo Molnar , Thomas Gleixner , Peter Zijlstra , Andi Kleen , Arjan van de Ven , Venkatesh Pallipadi , chris.mason@oracle.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: Export tsc related information in sysfs References: <4BF58B59.7080901@athenacr.com> <1274727116.2954.5.camel@localhost.localdomain> <4BFADF9D.9050209@zytor.com 1274733566.2954.73.camel@localhost.localdomain> <3ec7f284-1507-47fb-b5a2-eea29f68c627@default> <4BFAFE17.8060105@zytor.com> <4BFB2902.50308@athenacr.com> <4BFC687A.9040304@athenacr.com> <1274834888.4678.66.camel@localhost.localdomain> <4BFC8C77.7020802@athenacr.com> <1274886299.1759.8.camel@work-vm> <4BFD4629.6040602@athenacr.com> <1274891109.1759.27.camel@work-vm> <4BFD6C2B.4070403@athenacr.com> <1274903390.3383.17.camel@localhost.localdomain> In-Reply-To: <1274903390.3383.17.camel@localhost.localdomain> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/26/2010 03:49 PM, john stultz wrote: > On Wed, 2010-05-26 at 14:44 -0400, Brian Bloniarz wrote: >> On 05/26/2010 12:25 PM, john stultz wrote: >>> Brian: is this something the NTPd folks actually want? Has anyone >>> checked with them before we hand down the solution from high upon on >>> lkml mountain? >> >> I haven't checked, it's been a while since I dealt with >> this problem. The NTP maintainers definitely complain about the >> quick TSC calibration code like it's a bug: >> (e.g. http://www.mail-archive.com/questions@lists.ntp.org/msg02079.html). >> Anyway I'll reach out before I spend any time investing in >> a solution that they don't want (and you don't like :). >> >>> Personally I think NTPd should be a little more savvy about how far it >>> trusts the drift file when it starts up. Since I believe its >>> fast-startup mode can quickly estimate the drift well within 100ppm, >>> which is about the maximum variance I've seen from the calibration code. >> >> The workaround we went with was to remove the drift file on >> every reboot. But in our experience, even with iburst, converging takes >> a long time. I don't have hard numbers since it's been a long time since >> I investigated the problem, but we defined failure as >1ms offset syncing >> to a server in our LAN, and a cold NTP boot takes 10-20 hours to get >> there. > > Ok. If its been awhile, you may find recent kernels (2.6.31+) are much > faster to converge due to adjustments made to the SHIFT_PLL constant. > This was done explicitly to address issues similar to what you describe > above. My tests were pre-2.6.31, this is really good to know. I'll take another look on recent kernels.