On Fri, Jun 09, 2006 at 03:55:28PM -0400, Tom Lane wrote:
> Greg Stark <gsstark@mit.edu> writes:
> > There seem to be two types of overhead going on. There's the amount of time
> > spent in gettimeofday itself which is pretty consistent.
>
> That is a fact not in evidence. The impression I had from that
> linux-kernel discussion was that the problematic kernel code was looping
> until it got consistent results from successive hardware reads. I'm
> not at all sure that you can make the above assertion across all
> varieties of clock hardware, or even all common varieties.
The interesting thing about this is that they obviously are gearing
gettimeofday() to be accurate, rather than just considering it a
counter that is somewhat close to real time. At the expense of speed.
What we want is just a monotonically increasing counter that can be
read quickly and consistantly, we're not majorly fussed if it doesn't
match real time. This puts us back to CPU cycle counters, but they have
drawbacks of their own.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.