Re: gettimeofday nanoseconds patch (makes it possible for the

[john stultz <johnstul@us.ibm.com>]

On Thu, 2004-07-15 at 08:31, Christoph Lameter wrote:
> On Wed, 14 Jul 2004, David Mosberger wrote:
> 
> > >>>>> On Wed, 14 Jul 2004 17:48:06 -0700, john stultz <johnstul@us.ibm.com> said:
> >
> >   John> Although you still have the issue w/ NTP adjustments being
> >   John> ignored, but last time I looked at the time_interpolator code,
> >   John> it seemed it was being ignored there too, so at least your not
> >   John> doing worse then the ia64 do_gettimeofday(). [If I'm doing the
> >   John> time_interpolator code a great injustice with the above,
> >   John> someone please correct me]
> >
> > The existing time-interpolator code for ia64 never lets time go
> > backwards (in the absence of a settimeofday(), of course).  There is
> > no need to special-case NTP.
> >
> > With Christoph's changes, NTP is an issue again, however.
> 
> 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. 

Now, you cannot have time going backwards, so the solution is to cap the
output of time_interpolator_update() by insuring that during an NTP
adjusted tick, we do not return more then the NTP adjusted tick length
added to the base offset we calculated at the last timer interrupt.

Thus at time four above(and during the 99 usecs before it) we would
return (1000 + 900) instead of (1000+999). 

And again, the ia64 code isn't my specialty, so if I'm just being daft,
please let me know. 

thanks
-john