Re: [RFC][PATCH 2/2] Reduced NTP rework (part 2)

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

On Tue, 2005-09-27 at 18:37 +0200, Roman Zippel wrote:
> Hi,
> 
> On Thu, 22 Sep 2005, john stultz wrote:
> 
> > +
> > +	/* calculate the total continuous ppm adjustment */
> > +	total_sppm = time_freq; /* already shifted by SHIFT_USEC */
> > +	total_sppm += offset_adj_ppm << SHIFT_USEC;
> > +	total_sppm += tick_adj_ppm << SHIFT_USEC;
> > +	total_sppm += singleshot_adj_ppm << SHIFT_USEC;
> >  }
> 
> I'm not sure, why you still need this.
> As I already said, I don't think you need to change the kernel NTP model. 
> This means in particular that the NTP time is still incremented in fixed 
> intervals (although it's not necessary to do it at HZ frequency).
> I showed you how to do most of the calculation, so I'm a little confused, 
> why the above is still used.

Yea. I had spent some time implementing your idea about having a
reference xtime that is only NTP adjusted, then timesource based
system_time which adjusts the frequency of time timesource when
system_time and the ntp adjusted xtime drift apart. 

The biggest concern was having duplicate timekeeping subsystems in play
at once. 

With the approach I was taking earlier, I didn't like the idea of having
2 duplicate generic timekeeping systems that are different on different
arches, but I figured it would be be an improvement, since a number of
arches would then not need any arch specific timekeeping code (which is
not the case now).

However, with you idea, on some arches we have to keep two timekeeping
subsystems running at once, with code trying to smoothly synchronize
them. I got a little frustrated trying to generate a clean
implementation and decided to skip that idea for now. I'm not ruling it
out, but I wanted to explore some other ideas I have.

So I started playing with a few different approaches in the short term,
trying to adapt some of your ideas (such as using fixed interval time
accumulation to avoid the multiply at tick time) to my existing code.

Further I'm trying to slowly manipulate both the current tick based
update_wall_clock() and my timekeeping_periodic_hook() functions so that
they begin to resemble each other. This way I can begin to show
equivalence between the two. 


The idea being:

update_wall_clock():
	ticks = jiffies - wall_jiffies
	while (ticks):
		ticks--
		xtime += tick_nsec + ntp_adjustment


isn't that different from:

timekeeping_periodic_hook():
	now = timesource_read(ts)
	delta_cycle = now - last
	while (delta_cycle > interval_cycle):
		delta_cycle -= interval_cycle
		system_time += interval_nsec


Where ts is the jiffies timesource and the interval_nsec is a
precomputed equivalent to (tick_nsec + ntp_adjustment). 

The only difference between continuous and tick based systems would then
be in gettimeofday() (which really could be the same with a simple
#define)

continuous_gettimeofday():
	now = timesource_read(ts)
	delta_cycle = now - last
	delta_nsec = cyc2ns(timesource, delta_cycle)
	return system_time + delta_nsec

tick_gettime():
	now = timesource_read(jiffes_timesource)
	delta_cycle = now - last
	delta_nsec = cyc2ns(timesource, delta_cycle)
	delta_nsec += arch_get_offset()
	return system_time + delta_nsec


Which isn't all that different from the existing:
	usec = mach_gettimeoffset();
	lost = jiffies - wall_jiffies;
	/*
	 * If time_adjust is negative then NTP is slowing the clock
	 * so make sure not to go into next possible interval.
	 * Better to lose some accuracy than have time go backwards..
	 */
	if (unlikely(time_adjust < 0)) {
		usec = min(usec, max_ntp_tick);
		if (lost)
			usec += lost * max_ntp_tick;
	}
	else if (unlikely(lost))
		usec += lost * tick_usec;

	sec = xtime.tv_sec;
	usec += xtime.tv_nsec/1000;

Logic seen in the m68k time.c

With luck I'll have something more then just pseudo code to review soon.

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/