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

[Christoph Lameter]

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.

> > In that case maybe the "ticks" are the timesource and not really tick
> > processing per se.
>
> If I understand you, yes. In this case the timer interrupt counter
> (jiffies) is used as a free running counter.
>
> > There could be a separation between "increment counter" and tick processing.
>
> Could you expand on this?

The timesource is really a memory location incremented by "increment
counter" and not part of tick processing.  Logically these are seperate.
"increment counter" could happen apart from tick processing.
They are just conflated in the current tick implementation.
-
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/