[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 12:14, Christoph Lameter wrote:
    > On Wed, 8 Dec 2004, john stultz wrote:
    > > > With the improved scaling factor one should be able to come very close to
    > > > ntp scaled time without invoking ntp_scale itself. Tick processing will
    > > > then update time to be ntp scaled by fine tuning the scaling factor (with
    > > > the bit shifting we can get very fine tuning) and eventually skip a few
    > > > nanoseconds. Its basically some piece of interpolator logic in there so
    > > > that the heavyweight calculations can just be done once in a while.
    > >
    > > No. I agree ntp_scale() is a performance concern. However I'm not sure
    > > how your suggestion of just slowing or tweaking the timesource
    > > mult/shift frequency values will allow us to implement the expected
    > > behavior of adjtimex(). We need to be able to implement the following
    > > adjustments within a single tick:
    > >
    > > 1. Adjust the frequency by 500ppm for 10usecs
    > > 2. After that adjust the frequency by 30ppm for the rest of the tick.
    > Frequency adjustments just means an adjustment of the scaling factor.
    > Am I missing something?
    > > We can see how much of this can be fudged or generalized, but I'm
    > > hesitant to be too flippant about changing the NTP behavior for fear
    > > that the astronomers who so dearly care about leap seconds and minute
    > > time adjustments will "forget" to mention the asteroid heading towards
    > > my home. :)
    > I am not sure what NTP behavior needs to be fudged. Sorry about my limited
    > NTP knowledge. Could you elaborate on what the problem is?

    Take a look at the adjtimex man page as well as the ntp.c file from the
    timeofday core patch. There are number of different types of adjustments
    that are made, possibly at the same time. Briefly, they are (to my
    understanding - I'm going off my notes from awhile ago):
    o tick adjustments
    how much time should pass in a _user_ tick
    o frequency adjustments
    long term adjustment to correct for constant drift),
    o offset adjustments
    additional ppm adjustment to correct for current offset from the ntp
    o single shot offset adjustments
    old style adjtime functionality

    Tick, frequency and offset adjustments can be precalculated and summed
    to a single ppm adjustment. This is similar to the style of adjustment
    you propose directly onto the time source frequency values.

    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.

    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.

    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.


    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.306 / U:0.428 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site