lkml.org 
[lkml]   [2004]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] New Time of day proposal (updated 9/2/04)
    > timeofday_hook()
    > now = read(); /* read the timesource */
    > ns = cyc2ns(now - offset_base); /* calc nsecs since last call */
    > ntp_ns = ntp_scale(ns); /* apply ntp scaling */
    > system_time += ntp_ns; /* add scaled value to system_time */
    > ntp_advance(ns); /* advance ntp state machine by ns */
    > offset_base = now; /* set new offset_base */

    This would only work if the precision of the timer used is
    <=1ns and if you are actually able to caculate the nanoseconds that have
    passed. What do you do if the interval is lets say 100ns and the time the
    timeofday hook is being called can be anytime within this 100ns interval
    since the time source is not always precise?

    I think its unavoidable to do some correction like provided by the time
    interpolator if the clock source does not provide ns.

    > monotonic_clock()
    > now = read(); /* read the timesource */
    > ns = cyc2ns(now - offset_base); /* calculate nsecs since last hook */
    > ntp_ns = ntp_scale(ns); /* apply ntp scaling */
    > return system_time + ntp_ns; /* return system_time and scaled value

    This works analogous to the time interpolator today. The scaling of the
    timesource is omitted tough. Looks like we will be able to keep the
    fastcalls for clock_gettime and gettime ofday.

    > o What is the cost of throwing around 64bit values for everything?
    > - Do we need an arch specific time structure that varies size
    > accordingly?

    64bit may be necessary at a minimum because with 4Ghz machine we may
    have counters with the frequency >2^32 cycles per second.

    I would think that 128bit may be necessary (at least
    as an intermediate result during the scaling of the timesource to
    nanoseconds) since we want to be accurate to the nanosecond.

    > o Some arches (arm, for example) do not have high res timing hardware
    > - In this case we can have a "jiffies" timesource
    > - cyc2ns(x) = x*(NSEC_PER_SEC/HZ)
    > - doesn't work for tickless systems

    David M.s time interpolator logic is needed in those cases to insure that
    the clock works properly and that nanoseconds offset can be calculated in
    a consistent way although the exact timing of the increas / reading of the
    counter may vary within a certain time period.
    -
    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-03-22 14:05    [W:0.020 / U:118.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site