[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.021 / U:215.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site