already understood. I was using the return value of times() only,
which is the elapsed real time in scheduler ticks since boot.
> > gettimeofday(&tv, 0) would work, but I'd have to munge the
> > fields of tv together to get a single integer, e.g.
> > now = (tv.sec << 10) + (tv.usec >> 10)
>
> do you have a reason to believe that this kind of inaccurate scaling
> saves you more than a handful of cycles?
I don't need more than ms precision. Also, it's a matter of convenience.
If I switch to using tv's, my time comparison macro
inline bool clock_after(clock_t a, clock_t b)
{
long diff = (long) (a - b); /* avoids rollover errors */
return (diff > 0);
}
gets more complicated:
inline bool tv_after(const struct timeval &a, const struct timeval &b)
{
long diff = (long) (a.sec - b.sec);
if (diff) return (diff > 0); /* avoids rollover errors */
return a.usec > b.usec;
}
and I was too lazy to write it until just now. I've been using
system ticks for this longer than I can remember, so there was
a certain intertia... plus now I have to make sure tv_after works.
> > Do the recent posts on special entry points mean that this
> > would be faster than calling times()?
>
> not really. the syscall overhead dominates either call. but gtod
> is going to do more work (reading either the TSC or the counter/timer chip
> to calculate accurate time) than times (which just pulls a few tick-counters
> out of the process struct.
See http://kernelnotes.org/lnxlists/linux-kernel/lk_9912_02/msg00232.html
(a way to eliminate the syscall overhead) and ensuing discussion.
If this ever makes it into a real kernel, gtod() might be faster than times().
> > Am I better off using gettimeofday() anyway because of
> > its higher precision and clearer specification?
>
> how is times unclear?
Nowhere in the man pages does it explain what units 'clock tick' are in.
Following the man pages leads you to CLK_TCK, which is wrong (it's 1000000
rather than 100).
Only by oral tradition does one discover HZ or (much better)
sysconf(_SC_CLK_TCK).
IMHO 'man times' should mention sysconf(_SC_CLK_TCK), and depricate HZ,
CLK_TCK, and CLOCKS_PER_SEC.
Note also that 'man sysconf' claims that sysconf(_SC_CLK_TCK) == CLK_TCK,
which is untrue.
I'm still a bit confused about all that. I believe that SUS mandated
a certain value for CLOCKS_PER_SEC. Better to just erase it from the
face of the earth, since a compile time constant is just wrong for the
units of system scheduler ticks.
- Dan
-- (The above is just my personal opinion; I don't speak for my employer, except on the occasional talk show.)- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/