Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261713AbVAYB4C (ORCPT ); Mon, 24 Jan 2005 20:56:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261708AbVAYB4C (ORCPT ); Mon, 24 Jan 2005 20:56:02 -0500 Received: from omx1-ext.sgi.com ([192.48.179.11]:24213 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S261713AbVAYBzl (ORCPT ); Mon, 24 Jan 2005 20:55:41 -0500 Date: Mon, 24 Jan 2005 17:54:35 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: john stultz cc: lkml , Tim Schmielau , George Anzinger , albert@users.sourceforge.net, Ulrich Windl , Dominik Brodowski , David Mosberger , Andi Kleen , paulus@samba.org, schwidefsky@de.ibm.com, keith maanthey , Patricia Gaughen , Chris McDermott , Max Asbock , mahuja@us.ibm.com, Nishanth Aravamudan , Darren Hart , "Darrick J. Wong" , Anton Blanchard Subject: Re: [RFC][PATCH] new timeofday core subsystem (v. A2) In-Reply-To: <1106613222.30884.34.camel@cog.beaverton.ibm.com> Message-ID: References: <1106607089.30884.10.camel@cog.beaverton.ibm.com> <1106611416.30884.22.camel@cog.beaverton.ibm.com> <1106613222.30884.34.camel@cog.beaverton.ibm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1359 Lines: 33 On Mon, 24 Jan 2005, john stultz wrote: > We talked about this last time. I do intend to re-work ntp_scale() so > its not a function call, much as you describe above. > > hopelessly endeavoring, hehe.... But seriously: The easiest approach may be to modify the time sources to allow a fine tuning of the scaling factor. That way ntp_scale may be moved into tick processing where it would adjust the scaling of the time sources up or downward. Thus no ntp_scale in the monotonic clock processing anymore. Monotonic clocks could be calculated monotime = ns_at_last_tick + (time_source_cycles_since_tick * current_scaling_factor) >> shift_factor. This would also be easy to implement in asm if necessary. tick processing could then increment or decrement the current scaling factor to minimize the error between ticks. It could also add nanoseconds to ns_at_last_tick to correct the clock forward. With the appropiate shift_factor one should be able to fine tune time much more accurately than ntp_scale would do. Over time the necessary corrections could be minimized to just adding a few ns once in a while. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/