From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753501Ab1LINLQ (ORCPT ); Fri, 9 Dec 2011 08:11:16 -0500 Received: from mail1.nippynetworks.com ([91.220.24.129]:51195 "EHLO mail1.nippynetworks.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751819Ab1LINLP (ORCPT ); Fri, 9 Dec 2011 08:11:15 -0500 X-Greylist: delayed 581 seconds by postgrey-1.27 at vger.kernel.org; Fri, 09 Dec 2011 08:11:15 EST Message-ID: <4EE206AC.6060800@wildgooses.com> Date: Fri, 09 Dec 2011 13:01:32 +0000 From: Ed W User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: john stultz CC: linux-kernel@vger.kernel.org Subject: Re: Improved TSC calculation References: <4DA6D85A.8000800@wildgooses.com> <1302805253.2673.17.camel@work-vm> In-Reply-To: <1302805253.2673.17.camel@work-vm> X-TagToolbar-Keys: D20111209130132771 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 14/04/2011 19:20, john stultz wrote: > On Thu, 2011-04-14 at 12:19 +0100, Ed W wrote: >> Hi, Thanks for the new stable TSC calculation commit >> (08ec0c58fb8a05d3191d5cb6f5d6f81adb419798). >> >> My situation is that I don't have a PM or HPET timer (x86 Alix board), >> and my requirements are embedded type use, but with only intermittently >> connected network/gps, so accurate timekeeping between reboots is >> important. >> >> I had been experimenting with extending the existing PIT timer routines >> at boot, but I had the problem that it was taking 1s+ to get a very >> stable calculation (which is undesirable for my requirements), however, >> having spotted your commit it seems like a much more sensible solution. > Thanks! > >> Before I try and hack probably an (inadequate) solution myself, do you >> have any thoughts on the best solution to extend your commit to non >> PM/HEPT machine? My initial thought was to repeatedly call >> pit_calibrate_tsc() with an extended latch, looking for a stable >> solution (ie refactor native_calibrate_tsc() ). Is this workable? >> Better ideas? > Oof. So with the PIT you can maybe utilize the second channel/counter, > using a largish long countdown to try to get a similar functionality. > The only big concern is that the timer interrupt hardware is always > problematic (every time we chanage our usage, some random chunk of > laptops seem to stop working). So whatever solution that works for you > might not be able to be generically deployed. But I think it could be > interesting and might be worth you giving it a shot. > > I'd probably look at reworking tsc_refine_calibration_work, extending > the tsc_read_refs() code to also get PIT count values and then start the > long PIT countdown on the second channel before we > schedule_delayed_work. > > thanks > -john > Hi John I don't suppose you ever gave any thought to looking into this yourself... :-) I have had a poke, but I'm way out of my depth trying to figure out a good solution. For reference my goal was to get a stable TSC calculation for my PCEngines Alix boards, which are basically popular, low cost x86 compatible boards, but without HPET or PM. I rather want to use them as way to get more reliable Stratum 1 NTP servers out in the wild - hopefully by documenting them as a very low cost solution to pair with a GPS. Having them somewhat clock stable with respect to reboot would be handy It's a big ask, so understand that you are probably going to discard this email Thanks for listening and your advice so far All the best Ed W