Messages in this thread | | | Date | Fri, 17 Feb 2006 16:02:15 +0100 (CET) | From | Roman Zippel <> | Subject | Re: [patch] hrtimer: round up relative start time on low-res arches |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |