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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |