[lkml]   [2005]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC][PATCH 2/2] Reduced NTP rework (part 2)
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();
> sec = xtime.tv_sec;
> usec += xtime.tv_nsec/1000;
> Logic seen in the m68k time.c

Same code in most other archs.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-09-27 23:59    [W:0.084 / U:2.560 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site