Re: gettimeofday nanoseconds patch (makes it possible for theposix-timer functions to return higher accuracy)

[john stultz]

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/