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

[Roman Zippel]

Hi,

On Thu, 16 Feb 2006, john stultz wrote:

> > 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?

Here my example does correct for this error, it accumulates the difference 
between the clock update and the desired ntp update and once it's large 
enough, it's corrected by a multiplier change.

> 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?

I don't understand what the advantage would be, the NTP code needs both 
and the time interval is actually the variable part, so AFAICT it would 
make the NTP code only more complex. (NTP changes the amount of time to be 
passed per tick to adjust clock speed and not the other way around.)

bye, Roman
-
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/