From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261425AbULIBZV (ORCPT ); Wed, 8 Dec 2004 20:25:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261427AbULIBZV (ORCPT ); Wed, 8 Dec 2004 20:25:21 -0500 Received: from omx1-ext.sgi.com ([192.48.179.11]:42898 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S261425AbULIBZQ (ORCPT ); Wed, 8 Dec 2004 20:25:16 -0500 Date: Wed, 8 Dec 2004 17:24:08 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: john stultz cc: lkml , tim@physik3.uni-rostock.de, george anzinger , albert@users.sourceforge.net, Ulrich.Windl@rz.uni-regensburg.de, Len Brown , linux@dominikbrodowski.de, David Mosberger , Andi Kleen , paulus@samba.org, schwidefsky@de.ibm.com, keith maanthey , greg kh , Patricia Gaughen , Chris McDermott , Max , mahuja@us.ibm.com Subject: Re: [RFC] New timeofday proposal (v.A1) In-Reply-To: <1102553491.1281.297.camel@cog.beaverton.ibm.com> Message-ID: References: <1102470914.1281.27.camel@cog.beaverton.ibm.com> <1102533066.1281.81.camel@cog.beaverton.ibm.com> <1102535891.1281.148.camel@cog.beaverton.ibm.com> <1102549009.1281.267.camel@cog.beaverton.ibm.com> <1102551441.1281.286.camel@cog.beaverton.ibm.com> <1102553491.1281.297.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 On Wed, 8 Dec 2004, john stultz wrote: > Well, ok, you're right. I got my wires twisted and misspoke. Today we > really don't, since NTP adjustments only occur on tick boundaries. So > yes, singleshot adjustments are in multiples of ticks right now. But we > do assume ticks arrive at regular periods. If they don't, well, then we > apply it for only one ticks worth, but we've lost a tick so we're wrong > anyway. > > The code above, however, can handle non-regular interrupt intervals, > which is something I think we should assume will occur. Then we might also assume that we are beyond the technology of the eighties and that there is some way that hardware can give us an interrupt at a certain point in the future that will allow us to change the scaling factor? I think its safe to not do this two scale stuff. Too complex for the hot code path anyways.