lkml.org 
[lkml]   [2005]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC - 0/9] Generic timekeeping subsystem (v. B5)
    From
    Date
    On Mon, 2005-08-22 at 01:19 +0200, Roman Zippel wrote:
    > Hi,
    >
    > On Fri, 19 Aug 2005, john stultz wrote:
    >
    > > timekeeping_perioidic_hook():
    > >
    > > /* get ntp adjusted interval length*/
    > > interval_length = get_timesource_interval(ppm)
    >
    > Here starts the problem, this requires more expensive math than necessary,
    > as every time you first have to scale the values.

    Hmmm. I feel like we're mixing signals. See below for more on this.


    > Let's take a standard PIT timer as an example. With HZ=100 we program it
    > with 11932, for simplicity let's assume this corresponds to 10^7ns and
    > scale this by 2^8. This means the timer multiplier is initially 214549,
    > this updates the system time by 214549*11932 and the reference time by
    > 10^7*2^8 every tick. We can now just ignore the error or as soon as it
    > exceeds 11932/2 we increase/decrease the mutiplier. The error calculation
    > is rather simple, usually just adds and shifts, only if the error exceeds
    > 2*11932 it gets a little more complicated, but even here the possible
    > divide is avoidable.

    I feel like we're talking about different problems. Which reference
    clock (other then the system clock) are you wanting to increment at the
    tick time? Do you mean the ntp time_offset value? A little bit of psudo
    code might go a long way in helping me understand your solution.

    Also I'm not sure how this is connects to the continuous timesource
    situation where we do not assume timer ticks are not lost or late.


    > The gettimeofday would then basically be "xtime + (cycle_offset * mult +
    > error_offset) / 2^8". Depending on the update frequency and the required
    > precision it's even possible to keep this within 32bit. The ntp part stays
    > pretty much the same and the time source can add anything it wants on top
    > of that. The basic math is also pretty much the same so we can generate
    > most of the code depending on various parameters.


    Again, I must not be understanding what you're suggesting. Above where
    you called get_timesource_interval(ppm) too expensive, what you're
    suggesting here is almost exactly what get_timesource_interval(ppm)
    would do. In my timeofday patches, its called cyc2ns() and gettimeofday
    looks like:
    xtime + cyc2ns(timesource, ntp_adjustment, cycle_delta)

    Where cyc2ns does:
    (cycle_delta * (timesource->mult + ntp_adjustment))>>timesource->shift


    The reason why we calculate the interval_length in the continuous
    timesource case is because we are not assuming anything about the
    frequency that the timekeeping_periodic_hook() is called.


    Again, I'm really wanting to address your concerns, but I still do not
    really understand the specific objections.

    thanks
    -john



    -
    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-22 21:05    [W:0.025 / U:31.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site