Re: [PATCH] correct inconsistent ntp interval/tick_length usage

[John Stultz]

On Thu, 2008-01-31 at 06:02 +0100, Roman Zippel wrote:
> Hi,
> 
> On Wed, 30 Jan 2008, john stultz wrote:
> 
> > My concern is we state the accumulation interval is X ns long. Then
> > current_tick_length() is to return (X + ntp_adjustment), so each
> > accumulation interval we can keep track of the error and adjust our
> > interval length.
> > 
> > So if ntp_update_frequency() sets tick_length_base to be:
> > 
> > 	u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ)
> > 			<< TICK_LENGTH_SHIFT;
> > 	second_length += (s64)CLOCK_TICK_ADJUST << TICK_LENGTH_SHIFT;
> > 	second_length += (s64)time_freq
> > 				<< (TICK_LENGTH_SHIFT - SHIFT_NSEC);
> > 
> > 	tick_length_base = second_length;
> > 	do_div(tick_length_base, NTP_INTERVAL_FREQ);
> > 
> > 
> > The above is basically (X + part of ntp_adjustment)
> 
> CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't 
> based on HZ, there is no point in using it!

Hey Roman,

Again, I'm sorry I don't seem to be following your objections. If you
want to suggest a different patch to fix the issue, it might help.

The big issue for me, is that we have to initialize the clocksource
cycle interval so it matches the base tick_length that NTP uses.

To be clear, the issue I'm trying to address is only this:
Assuming there is no NTP adjustment yet to be made, if we initialize the
clocksource interval to X, then compare it with Y when we accumulate, we
introduce error if X and Y are not the same.

It really doesn't matter how long the length is, if we're including
CLOCK_TICK_ADJUST, or if it really matches the actual HZ tick length or
not. The issue is that we have to be consistent. If we're not, then we
introduce error that ntpd has to additionally correct for.

Now, once we're consistent, then CLOCK_TICK_ADJUST can be zero or not
and it won't really matter, other then making sure we accumulate at
exact tick length units. You can set it either way with my patch and
things will still work out to be correct.

My apologies for being so thick headed if I'm just missing something. I
do appreciate the feedback.
-john

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