From mboxrd@z Thu Jan 1 00:00:00 1970 From: john stultz Date: Thu, 15 Jul 2004 17:18:28 +0000 Subject: Re: gettimeofday nanoseconds patch (makes it possible for the Message-Id: <1089911907.15272.35.camel@leatherman> List-Id: References: <1089835776.1388.216.camel@cog.beaverton.ibm.com> <1089839740.1388.230.camel@cog.beaverton.ibm.com> <1089852486.1388.256.camel@cog.beaverton.ibm.com> <16629.56037.120532.779793@napali.hpl.hp.com> <1089908059.15272.29.camel@leatherman> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Christoph Lameter Cc: davidm@hpl.hp.com, george anzinger , lkml , ia64 On Thu, 2004-07-15 at 10:03, Christoph Lameter wrote: > On Thu, 15 Jul 2004, john stultz wrote: > > > > The old code only insured that the interpolated offset in nanoseconds > > > after a timer tick never goes backward. Negative corrections to xtime > > > could also result in time going backward since the offset is > > > always added to xtime. Both the old and the new code use the logic in > > > time_interpolator_update (invoked when xtime is advanced) to compensate > > > for this situation. > > > > However it seems this compensation also negates NTPs adjustment. There > > is nothing that scales the time_interpolator_update's output. > > > > A quick example: > > So lets say tick length is 1000us. At time zero we call gettimeofday(), > > it returns xtime + time_interpolator_update(), both return zero. 999us > > later at time two, the same thing happens and we return (0 + 999). A > > usec later at time three, the timer interrupt is called and xtime is > > incremented 1000us, and time_interpolator decrements 1000us. Thus a call > > to gettimeofday would return (1000 + 0). Immediately following, adjtimex > > is called, setting the tick length to 900us. Then 999 usecs later at > > time four, we return (1000 + 999). The next usec at time five, the timer > > interrupt goes off and increments xtime by 900, and decrements the > > time_interpolator by 900. Thus a call to gettimeofday() would return > > (1900 + 100). So rather returning the proper NTP adjusted time of 1900, > > 2000 is being returned as if the NTP adjustment never occured. > > The above omits some details but is basically correct. Note that the > time_interpolator gradually brings time back into sync with xtime because > it looses a few nanoseconds (depending on the clock) each tick. At > some point the correction asked for by the timer tick will be greater than the > offset and at that time the offset is set to zero. Then a resync has > occurred. Hmmm. I haven't noticed that bit. I'll have to look at it again. Thanks for the pointer. > > Thus at time four above(and during the 99 usecs before it) we would > > return (1000 + 900) instead of (1000+999). > > Having time stand still is an awkward solution: Time may stand > still even longer if the tick is delayed and then time suddenly jumps > ahead when the tick finally occurs. > > The existing implementation slowly compensates and is the best solution > IMHO. Indeed capping time is awkward, I'm working on rewriting the NTP code so that it appropriately and consistently scales the inter-tick time. But again, that'll hopefully be a 2.7 thing. thanks for the clarifications -john