[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, 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?
    > I may have asked this before, but w/ 32 bit mult and shifts, how
    > granular can these adjustments be?

    Yes. 128bit would be great for this. 64bit is fine though as
    far as I can see and allows granularity up to fractions of
    nanoseconds if applied between 1ms intervals.

    > Also additional complications arise when we have multiple things (like
    > cpufreq) playing with the timesource frequency values as well.

    I think these could all be taken into account by a scaling factor off a
    certain base established at a tick-like event that does the ntp scaling.
    The scaling between tick-like event needs to be just a scaling factor for
    performance reasons.

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