Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

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

On Mon, 2005-08-22 at 01:19 +0200, Roman Zippel wrote:
> Hi,
> 
> On Fri, 19 Aug 2005, john stultz wrote:
> 
> > timekeeping_perioidic_hook():
> > 
> > 	/* get ntp adjusted interval length*/
> > 	interval_length = get_timesource_interval(ppm)
> 
> Here starts the problem, this requires more expensive math than necessary, 
> as every time you first have to scale the values.

Hmmm. I feel like we're mixing signals. See below for more on this. 


> Let's take a standard PIT timer as an example. With HZ=100 we program it 
> with 11932, for simplicity let's assume this corresponds to 10^7ns and 
> scale this by 2^8. This means the timer multiplier is initially 214549, 
> this updates the system time by 214549*11932 and the reference time by 
> 10^7*2^8 every tick. We can now just ignore the error or as soon as it 
> exceeds 11932/2 we increase/decrease the mutiplier. The error calculation 
> is rather simple, usually just adds and shifts, only if the error exceeds 
> 2*11932 it gets a little more complicated, but even here the possible 
> divide is avoidable.

I feel like we're talking about different problems. Which reference
clock (other then the system clock) are you wanting to increment at the
tick time? Do you mean the ntp time_offset value? A little bit of psudo
code might go a long way in helping me understand your solution.

Also I'm not sure how this is connects to the continuous timesource
situation where we do not assume timer ticks are not lost or late. 


> The gettimeofday would then basically be "xtime + (cycle_offset * mult + 
> error_offset) / 2^8". Depending on the update frequency and the required 
> precision it's even possible to keep this within 32bit. The ntp part stays 
> pretty much the same and the time source can add anything it wants on top 
> of that. The basic math is also pretty much the same so we can generate 
> most of the code depending on various parameters.


Again, I must not be understanding what you're suggesting.  Above where
you called get_timesource_interval(ppm) too expensive, what you're
suggesting here is almost exactly what get_timesource_interval(ppm)
would do.  In my timeofday patches, its called cyc2ns() and gettimeofday
looks like:
  xtime + cyc2ns(timesource, ntp_adjustment, cycle_delta)

Where cyc2ns does:
  (cycle_delta * (timesource->mult + ntp_adjustment))>>timesource->shift


The reason why we calculate the interval_length in the continuous
timesource case is because we are not assuming anything about the
frequency that the timekeeping_periodic_hook() is called.


Again, I'm really wanting to address your concerns, but I still do not
really understand the specific objections. 

thanks
-john



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/