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

[George Anzinger]

Christoph Lameter wrote:
> 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.

Right.  We seem to be doing ok now by just adjusting things at tick time and 
using the "normal" interpolation between ticks.

As for the math, the current code keeps a running "remainder" which is the 
amount of the correction that was finer than the clock resolution (i.e. less 
than a nano second) and rolls this in on the next tick.  This gives resolution 
out to several bits to the right of the nano second.  And I think this is all 
done with 32 bit math (if memory serves).
>

--
George Anzinger   george@xxxxxxxxxx
High-res-timers:  http://sourceforge.net/projects/high-res-timers/

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