Re: [RFC] New Time of day proposal (updated 9/2/04)

From: Christoph Lameter
Date: Thu Sep 02 2004 - 22:04:32 EST


> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/