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

[john stultz <johnstul@us.ibm.com>]

On Wed, 2004-12-08 at 15:53, Christoph Lameter wrote:
> On Wed, 8 Dec 2004, john stultz wrote:
> > 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.
> 
> We would need to schedule a special tick like event at a certain time but
> otherwise I do not see a problem. Is there a requirement that these
> "specific amounts of time" are less than 1 ms? The timer hardware (such as
> the RTC clock) can generate an event in <200ns that could be used to
> change the scaling. For a tickless system we would need to have such
> scheduled events anyways.

Eh, I'd like to not to be dependent on event accuracy/frequency. Lets
see if we can do it w/o scheduling events. 

> > 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.
> 
> That looks troublesome. Better avoid that.

Well, its not *that* bad. Similar to the ntp_scale() function, it would
look something like:

if (interval <= offset_len)
	return (interval * singleshot_mult)>>shift;
else {
	cycle_t v1,v2;
	v1 = (offset_len * singleshot_mult)>>shift;
	v2 = (interval-offset_len)*adjusted_mult)>>shift;
	return v1+v2;
}

Where:
	singleshot_mult = original_mult + ntp_adj + ss_mult
and
	adjusted_mult = original_mult + ntp_adj


> > 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.
> 
> I am still suffering from my limited NTP knowlege but will see what I can
> do about this.

:) Any added NTP knowledge would be great to add to the pool. 

-john