Re: [patch] hrtimer: round up relative start time on low-res arches

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

On Fri, 2006-02-17 at 00:44 +0100, Roman Zippel wrote:
> On Thu, 16 Feb 2006, john stultz wrote:
> > > In the end the simplification of my patches should also 
> > > make your patches simpler, as it precalculates as much as possible and 
> > > reduces the work done in the fast paths. It would avoid a lot of extra 
> > > work, which you currently do.
> > 
> > Well, I'm still cautious, since it still has some dependencies on HZ
> > (see equation below), which I'm trying to avoid.
> 
> There is no real dependency on HZ, it's just that the synchronisations 
> steps and incremental updates are done in fixed intervals. The interval 
> could easily be independent of HZ.

Ok, one concern was that in the cycle->interval conversion, some
interval lengths are not possible due to the clock's resolution.

In my mind, I'd like to provide a interval length to the NTP code and
have the NTP code provide an adjusted interval which can be used in
error accumulation and the resulting multiplier adjustment.

Or, we just write off the cycle->interval error as part of the clock's
natural error and let the NTP daemon compensate for it. Your thoughts?

Regardless, the point is that I'd prefer if the timeofday code to be
able to specify to the NTP code what the interval length is, rather then
the other way around. Does that sound reasonable?

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/