Re: Is there any way to obtain a low-resolution timestamp fast?

Bob Hauck <postmaster@xxxxxxxxxxxxx> writes:
Rainer Weikusat <rweikusat@xxxxxxxxxxx> wrote:

[...]

A computer running a (modified) 2.4.36.6-kernel on a 200 Mhz ARM926
CPU which 'happens' to sit on my desk next to my monitor is capable of
executing 10,000,000 time(2) calls in about 18.7s, one every 1.87
usecs (1E-6s)[*]. Are you sure that your measurement/ estimate is
correct? And if so, what type of system are you using for development?

Interesting. The run time depends strongly on whether you call
gettimeofday() or time() and on whether or not you pass a parameter to
time(). This is a Core Duo (not Core2) @1.2 GHz, Debian 5.0.1 with
kernel 2.6.26-2-686.

Code:

int main(int argc, char* argv[])
{
time_t tt;
struct timeval tp;
int i;

for(i = 0 ; i < atoi(argv[1]) ; ++i) {
// tt = time(NULL);
// time(&tt);
// gettimeofday(&tp, NULL);
}
}


Calling gettimeofday():

hauck@scheme:~$ time ./a.out 10000000
real 0m15.688s
user 0m2.756s
sys 0m12.857s

Calling tt = time(NULL):

hauck@scheme:~$ time ./a.out 10000000
real 0m2.201s
user 0m1.084s
sys 0m1.116s


Calling time(&tt):

hauck@scheme:~$ time ./a.out 10000000
real 0m3.753s
user 0m2.600s
sys 0m1.104s

This is easily explained: In the older kernel I was using (because I
wanted to use the 'slow' CPU), the implementation of time(2) basically
does an 'internal gettimeofday' and throws away the excess precision.
This is not true anymore for 2.6, where time(2) just reads a variable
of type 'long', while gettimeofday does something significantly more
complicated in order to provide as accurate a timestamp as possible.
The difference between the two time-calls is likely because of the
additional copying involved when returning the time-value twice.
.

Relevant Pages