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

[john stultz]

On Thu, 2004-09-02 at 15:09, Christoph Lameter wrote:
> > 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?

Well, with the exception of the TSC, none of the current time sources
have <=1ns resolution, but I'm not sure I understand the problem you're
trying to point out. Could you clarify?

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

Could you point to the specific correction you describe? 

> > 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.

I worry 128bit math might be a bit too rich for the majority of systems
at the moment. I am open to it, although I suspect we can use other
tricks to get the same accuracy within a constrained bitspace.

> > 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.

Again, could you point me to the code (is this with your new patch, or
the older code)? I've looked at the time interpolator code, but I'm not
sure exactly what you mean. 

Thanks for the feedback! I really appreciate it!
-john

-
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/