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

[john stultz]

On Wed, 2004-12-08 at 12:14, 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?

Take a look at the adjtimex man page as well as the ntp.c file from the
timeofday core patch. There are number of different types of adjustments
that are made, possibly at the same time. Briefly, they are (to my
understanding - I'm going off my notes from awhile ago): 
o tick adjustments
	how much time should pass in a _user_ tick
o frequency adjustments
	long term adjustment to correct for constant drift), 
o offset adjustments
	additional ppm adjustment to correct for current offset from the ntp
server
o single shot offset adjustments 
	old style adjtime functionality

Tick, frequency and offset adjustments can be precalculated and summed
to a single ppm adjustment. This is similar to the style of adjustment
you propose directly onto the time source frequency values. 

However, there is also this short term single shot adjustments. These
adjustments are made by applying the MAX_SINGLESHOT_ADJ (500ppm) scaling
for an amount of time (offset_len) which would compensate for the
offset. This style is difficult because we cannot precompute it and
apply it to an entire tick. Instead it needs to be applied for just a
specific amount of time which may be only a fraction of a tick. When we
start talking about systems with irregular tick frequency (via
virtualization, or tickless systems) it becomes even more problematic. 

If this can be fudged then it becomes less of an issue. Or at worse, we
have to do two mult/shift operations on two "parts" of the time interval
using different adjustments.

Its starting to look doable, but its not necessarily the simplest thing
(for me at least). I'll put it on my list, but patches would be more
then welcome. 

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