lkml.org 
[lkml]   [2005]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
    Hi,

    On Tue, 16 Aug 2005, john stultz wrote:

    > If they are private clock variables, why are they in the generic
    > timer.c? Everyone is using it in exactly the same way, no? Why do you
    > oppose having the adjustment and phase values behind an ntp_function()
    > interface?

    These values belong to the clock, NTP specifies the speed of the clock via
    tick/frequency, these variables specify the current state of the clock. If
    we assume there is only one system clock, we need only one set of those,
    so leaving them in timer.c doesn't really hurt. How these variables are
    updated depends on the clock, so separating them doesn't make much sense.

    > Maybe to focus this productively, I'll try to step back and outline the
    > goals at a high level and you can address those.
    >
    > My Assumptions:
    > 1. adjtimex() sets/gets NTP state values
    > 2. Every tick we adjust those state values
    > 3. Every tick we use those values to make a nanosecond adjustment to
    > time.
    > 4. Those state values are otherwise unused.
    >
    > Goals:
    > 1. Isolate NTP code to clean up the tick based timekeeping, reducing the
    > spaghetti-like code interactions.
    > 2. Add interfaces to allow for continuous, rather then tick based,
    > adjustments (much how ppc64 does currently, only shareable).

    Cleaning up the code would be nice, but that shouldn't be the priority
    right now, first we should get the math right.
    I looked a bit more on this aspect of your patch and I think it's overly
    complex even for continuous time sources. You can reduce the complexity
    by updating the clock in more regular intervals.

    What basically is needed to update in constant intervals (n cycles) a
    reference time controlled via NTP and the system time. The difference
    between those two can be used to adjust the cycle multiplier for the next
    n cycles to speed up or slow down the system clock.
    Calculating the offset in constant intervals makes the math a lot simpler,
    basically the current code is just a special case of that, where it
    directly updates the system time from the reference time at every tick.
    (In the end the differences between tick based and continuous sources may
    be even smaller than your current patches suggest. :) )

    bye, Roman
    -
    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-08-19 02:30    [W:4.122 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site