Messages in this thread | | | Date | Fri, 21 Mar 2003 11:43:00 -0800 | From | Joel Becker <> | Subject | Re: Clock monotonic a suggestion |
| |
On Fri, Mar 21, 2003 at 12:01:13AM -0800, george anzinger wrote: > To carry this to the absurd, it also precludes most anything other > than a GPS or WWV based clock. If we are to have any clock that is
No, cycle counters do just fine.
> >1 gettimeofday = 1000000000 > >2 driver delays 10s > >3 gettimeofday = 1000000000 > >4 timer notices lag and adjusts > > Uh, how is this done? At this time there IS correction for delays up > to about a second built into the gettimeofday() code. You seem to be > assuming that we can do better than this with clock monotonic. Given > the right hardware, this may even be possible, but why not correct > gettimeofday in the same way?
monotonic_clock as proposed uses a hardware clock. Specifically, the TSC on vanilla intel, the Cyclone timer on x440, and associated clocks on S/390 (to speak of platforms I've visited recently). Right now, the hangcheck-timer accesses the hardware counter directly. monotonic_clock is intended as a portable and consistent accessor instead. The current gettimeofday() corrects for ~1s. Even if we found a way to correct for ~1000s or more, there would still be a race between when the caller reads and when the correction happens. A clock that reads a hardware counter doesn't have this problem. If code doesn't need this accuracy, it can just use gettimeofday().
Joel
--
"Glory is fleeting, but obscurity is forever." - Napoleon Bonaparte
Joel Becker Senior Member of Technical Staff Oracle Corporation E-mail: joel.becker@oracle.com Phone: (650) 506-8127 - 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/
| |