lkml.org 
[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)
From
Date
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/

\
 
 \ /
  Last update: 2005-09-27 23:59    [from the cache]
©2003-2011 Jasper Spaans