Messages in this thread | | | Subject | Re: [RFC][PATCH 2/2] Reduced NTP rework (part 2) | From | Thomas Gleixner <> | Date | Tue, 27 Sep 2005 23:57:57 +0200 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |