Re: [RFC] New timeofday proposal (v.A1)

[john stultz]

On Wed, 2004-12-08 at 11:20, Christoph Lameter wrote:
> On Wed, 8 Dec 2004, john stultz wrote:
> 
> > > > Points I'm glossing over for now:
> > > > ====================================================
> > > >
> > > > o ntp_scale(ns):  scales ns by NTP scaling factor
> > > > 	- see ntp.c for details
> > > > 	- costly, but correct.
> > >
> > > Please do not call this function from monotonic_clock but provide some
> > > sort of scaling factor that is adjusted from time to time.
> >
> > You're going to have to expand on this. I had considered only NTP
> > scaling the wall time, but for consistency it made more sense to me that
> > we also apply NTP scaling to the monotonic clock. This avoids different
> > notions of nanoseconds, one being the inaccurate unajusted system
> > nanoseconds and the other being the accurately ntp scaled wall time
> > nanoseconds. Trying to keep things sane.
> 
> It certainly is more consistent but its a big performance hit if that
> scaling is done on every invocation of clock_gettime or gettimeofday().
> 
> With the improved scaling factor one should be able to come very close to
> ntp scaled time without invoking ntp_scale itself. Tick processing will
> then update time to be ntp scaled by fine tuning the scaling factor (with
> the bit shifting we can get very fine tuning) and eventually skip a few
> nanoseconds. Its basically some piece of interpolator logic in there so
> that the heavyweight calculations can just be done once in a while.

No. I agree ntp_scale() is a performance concern. However I'm not sure
how your suggestion of just slowing or tweaking the timesource
mult/shift frequency values will allow us to implement the expected
behavior of adjtimex().  We need to be able to implement the following
adjustments within a single tick:

1. Adjust the frequency by 500ppm for 10usecs 
2. After that adjust the frequency by 30ppm for the rest of the tick.

We can see how much of this can be fudged or generalized, but I'm
hesitant to be too flippant about changing the NTP behavior for fear
that the astronomers who so dearly care about leap seconds and minute
time adjustments will "forget" to mention the asteroid heading towards
my home. :) 

I may have asked this before, but w/ 32 bit mult and shifts, how
granular can these adjustments be?

Also additional complications arise when we have multiple things (like
cpufreq) playing with the timesource frequency values as well. 


thanks again for the thorough review!
-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/