[lkml]   [2004]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] New timeofday proposal (v.A1)
    On Wed, 2004-12-08 at 15:53, Christoph Lameter wrote:
    > On Wed, 8 Dec 2004, john stultz wrote:
    > > However, there is also this short term single shot adjustments. These
    > > adjustments are made by applying the MAX_SINGLESHOT_ADJ (500ppm) scaling
    > > for an amount of time (offset_len) which would compensate for the
    > > offset. This style is difficult because we cannot precompute it and
    > > apply it to an entire tick. Instead it needs to be applied for just a
    > > specific amount of time which may be only a fraction of a tick. When we
    > > start talking about systems with irregular tick frequency (via
    > > virtualization, or tickless systems) it becomes even more problematic.
    > We would need to schedule a special tick like event at a certain time but
    > otherwise I do not see a problem. Is there a requirement that these
    > "specific amounts of time" are less than 1 ms? The timer hardware (such as
    > the RTC clock) can generate an event in <200ns that could be used to
    > change the scaling. For a tickless system we would need to have such
    > scheduled events anyways.

    Eh, I'd like to not to be dependent on event accuracy/frequency. Lets
    see if we can do it w/o scheduling events.

    > > If this can be fudged then it becomes less of an issue. Or at worse, we
    > > have to do two mult/shift operations on two "parts" of the time interval
    > > using different adjustments.
    > That looks troublesome. Better avoid that.

    Well, its not *that* bad. Similar to the ntp_scale() function, it would
    look something like:

    if (interval <= offset_len)
    return (interval * singleshot_mult)>>shift;
    else {
    cycle_t v1,v2;
    v1 = (offset_len * singleshot_mult)>>shift;
    v2 = (interval-offset_len)*adjusted_mult)>>shift;
    return v1+v2;

    singleshot_mult = original_mult + ntp_adj + ss_mult
    adjusted_mult = original_mult + ntp_adj

    > > Its starting to look doable, but its not necessarily the simplest thing
    > > (for me at least). I'll put it on my list, but patches would be more
    > > then welcome.
    > I am still suffering from my limited NTP knowlege but will see what I can
    > do about this.

    :) Any added NTP knowledge would be great to add to the pool.


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