[lkml]   [2005]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] new timeofday core subsystem (v. A2)
    On Mon, 24 Jan 2005, john stultz wrote:

    > We talked about this last time. I do intend to re-work ntp_scale() so
    > its not a function call, much as you describe above.
    > hopelessly endeavoring,

    hehe.... But seriously: The easiest approach may be to modify the time
    sources to allow a fine tuning of the scaling factor. That way ntp_scale
    may be moved into tick processing where it would adjust the scaling of the
    time sources up or downward. Thus no ntp_scale in the monotonic clock
    processing anymore.

    Monotonic clocks could be calculated

    monotime = ns_at_last_tick + (time_source_cycles_since_tick *
    current_scaling_factor) >> shift_factor.

    This would also be easy to implement in asm if necessary.

    tick processing could then increment or decrement the current scaling
    factor to minimize the error between ticks. It could also add
    nanoseconds to ns_at_last_tick to correct the clock forward.

    With the appropiate shift_factor one should be able to fine tune time much
    more accurately than ntp_scale would do. Over time the necessary
    corrections could be minimized to just adding a few ns once in a while.

    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-03-22 14:09    [W:0.019 / U:60.696 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site