lkml.org 
[lkml]   [1999]   [Dec]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gettimeofday() a special case : faster than times()?
Mark Hahn wrote:
> > Here's a newbie question about the merits of gettimeofday()
> > versus times() for implementing one's own little timers.
>
> gettimeofday returns elapsed (real) time in us. times returns
> various times in scheduler ticks (10ms on ia32).

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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.037 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site