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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
