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

[Thomas Gleixner]

On Tue, 2005-09-27 at 13:19 -0700, john stultz wrote:
> 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. 

Which would be wrong IMNSHO.

Please keep the current xtime centric implementation out of your mind. 

As I pointed out in the ktimers thread already the  correct chain of
processing is

raw timesource 
	-> freqency adjustment (== CLOCK_MONOTONIC) 
		-> wall time adjustment (== CLOCK_REALTIME)

This is the way all real world time sources work. Nobody screws on an
atomic clock because the earth rotation is not constant. Why should
Linux be different ? For historic reasons - because it was that way
since v0.95 ?

There is no performance penalty involved doing it this way. It just
changes the order of corrections. The performance critical stuff is a
question of implementation details not of processing order.

> Which isn't all that different from the existing:
> 	usec = mach_gettimeoffset();
<SNIP>
> 	sec = xtime.tv_sec;
> 	usec += xtime.tv_nsec/1000;
> 
> Logic seen in the m68k time.c

Same code in most other archs.

tglx

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