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

From: Christoph Lameter
Date: Wed Dec 08 2004 - 15:18:08 EST


On Wed, 8 Dec 2004, john stultz wrote:

> > 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.

Frequency adjustments just means an adjustment of the scaling factor.
Am I missing something?

> 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 am not sure what NTP behavior needs to be fudged. Sorry about my limited
NTP knowledge. Could you elaborate on what the problem is?
>
> I may have asked this before, but w/ 32 bit mult and shifts, how
> granular can these adjustments be?

Yes. 128bit would be great for this. 64bit is fine though as
far as I can see and allows granularity up to fractions of
nanoseconds if applied between 1ms intervals.

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

I think these could all be taken into account by a scaling factor off a
certain base established at a tick-like event that does the ntp scaling.
The scaling between tick-like event needs to be just a scaling factor for
performance reasons.


-
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/