Skip to main content
gamedev.net
🔒 Locked

High-Resolution Timer Problems

Started by shrtysk8r1 Oct 12, 2005 at 11:18 AM 5 replies 1.2k views
Original Post
shrtysk8r1
shrtysk8r1

double Platform::GetSystemTime(void)
{
	static timeval currentTime;
		
	// Get the current time..
	gettimeofday(&currentTime, 0);
		
	return (double)(currentTime.tv_sec) + ((double)(currentTime.tv_usec) * 0.000001);
}
The function returns the same value at all times..can anyone offer a fix or a better way for high-resolution timing on *nix platforms?
etothex
etothex
Which value does it return? And what *nix?
shrtysk8r1
shrtysk8r1
Well it returns a different value..but it changes so rarely that it seems like a precision problem. Was tested on Debian 3.0 systems and an Ubuntu 5.10.
Ravuya
Ravuya
I think gettimeofday() returns seconds since epoch. It's not a very decent high-resolution timer. According to the man page on BSD, it is supposed to also deliver microsecond precision, but also cautions that the accuracy is hardware dependent.

Consider using SDL -- it has the SDL_GetTicks() method which is millisecond accurate.
smitty1276
smitty1276
I think gettimeofday() returns seconds since epoch. It's not a very decent high-resolution timer.

No, it returns seconds since epoch in the tv_sec value, and the number of microseconds beyond that in the tv_usec term. You get 1/1000000 second precision.

When I implemented a high-prec timer using gettimeofday, I stored a start time and reported the computed times relative to it.

timeval start;gettimeofday(&start, 0)timeval current;gettimeofday(&current, 0);float elapsedSec, elapsedMicro;if (current.tv_sec == start.tv_sec)  elapsedSec = 0.0f;else  elapsedSec = current.tv_sec - start.tv_sec + 1;elapsedMicro = 1.0 - (start.tv_usec - current.tv_usec) * .000001;return (elapsedSec + elapsedMicro);


Or something close to that anyway...

The problem you are having may have to do with the fact that you are storing 8 bytes of second data and the microsecond data in an 8 byte float. You're losing something somewhere. Reduce it to small elapsed times that will fit into 8 bytes (or four bytes or whatever).

Of course, I may be completely wrong.

EDIT: Didn't I read a couple of months back that the epoch timer deal had just rolled over and was using the final bit now? Definately a precision issue.
shrtysk8r1
shrtysk8r1
Thanks alot, the problem most definitely was precision/overflow. The solution was to store the current time at initialization, and return the elapsed time.
Ravuya
Ravuya
Quote:
Original post by smitty1276
I think gettimeofday() returns seconds since epoch. It's not a very decent high-resolution timer.

No, it returns seconds since epoch in the tv_sec value, and the number of microseconds beyond that in the tv_usec term. You get 1/1000000 second precision.


My mistake. Thanks for correcting me.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.