`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 referenceclock (other then the system clock) are you wanting to increment at thetick time? Do you mean the ntp time_offset value? A little bit of psudocode might go a long way in helping me understand your solution.Also I'm not sure how this is connects to the continuous timesourcesituation 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 whereyou called get_timesource_interval(ppm) too expensive, what you'resuggesting here is almost exactly what get_timesource_interval(ppm)would do.  In my timeofday patches, its called cyc2ns() and gettimeofdaylooks like:  xtime + cyc2ns(timesource, ntp_adjustment, cycle_delta)Where cyc2ns does:  (cycle_delta * (timesource->mult + ntp_adjustment))>>timesource->shiftThe reason why we calculate the interval_length in the continuoustimesource case is because we are not assuming anything about thefrequency that the timekeeping_periodic_hook() is called.Again, I'm really wanting to address your concerns, but I still do notreally understand the specific objections. thanks-john-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`