asked on

Problem with QueryPerformanceCounter()

I'm doing a timing routine which uses QueryPerformanceCounter() but seems to get a bad tick count from QueryPerformanceCounter() now and then. The app is compiled in VC6 sp3 and run on NT4.0 sp5. Here's what happens:

1 - Call QueryPerformanceFrequency() to get ticks per second.

2 - Call QueryPerformanceCounter() to get the start time

3 - Do some work (and wait using a waitable timer)

4 - Call QueryPerformanceCounter() to get the end time

5 - Get delta time (end - start) and use it

6 - Set start time = end time

7 - Go to step 4 until all work done

The delta I get back sometimes indicates a tick count greater than 73K seconds. Bloody long time. The actual time I spend in the loop is on the order of 100 ms though. I (and several others) have checked the logic and it appears fine (and like I said, this only happens sometimes).

I use the performance counter because we need very tight resolution. Has anyone has seen problems like this with QueryPerformanceCounter() before?

ASKER CERTIFIED SOLUTION

fl0yd

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Grailman

ASKER

We check the returns and throw if if is FALSE.

We actually use unsigned __int64 (cast to LARGE_INTEGER) ) so that we can do calculations a bit easier. The frequency is used to giva a value of ms per second. The calls we use are:

CHECK_FN_THROW(QueryPerformanceFrequency(
reinterpret_cast<LARGE_INTEGER *>(&i64Freq)))

i64MSPerSec = i64Freq / 1000;

CHECK_FN_THROW(QueryPerformanceCounter(
reinterpret_cast<LARGE_INTEGER *>(&i64Start)))

CHECK_FN_THROW(QueryPerformanceCounter(
reinterpret_cast<LARGE_INTEGER *>(&i64End)))

With the ticks per second returned on our machines, an unsigned 64 bit number should hold 397 years worth of ticks so I don't think we have a wrap-around condition. I'll check the website & see if there's anything there that helps.

Grailman

DanRollins

What is the value of 64Freq after the first call? If it is near to 1000, then you will see some wild descrpencies (becauee you are dividing it by 1000).

-- Dan

jemax

Hi,
__int64 i64MSPerSec;
CHECK_FN_THROW(QueryPerformanceFrequency(
reinterpret_cast<LARGE_INTEGER *>(&i64Freq)))

i64MSPerSec = i64Freq / 1000
it is incorrect, QueryPerformanceFrequency returns you counts/per sec, so you don't need to /1000 it again
Additionally, you loose precision using '/' 500/1000 = 0, in that case

You could:
QueryPerformanceFrequency( (LARGE_INTEGER *)&freq );

QueryPerformanceCounter( (LARGE_INTEGER *)&bt );
...
QueryPerformanceCounter( (LARGE_INTEGER *)&et );

_int64 elapsed = et - bt;
double secs = (double)elapsed / (double)freq;

HTH,
jemax
P.S. As you know, using QueryPerformanceCounter you measure how much time passed at all. It doesn't show you the real time of your code execution, because of the thread switching.

you will get incorrect results, since you loose .xx part, so you get 500/1000 = 0

jemax

Please ingore the last line :)

Grailman

ASKER

fl0yd:
My problem actually turned out to be a stack corruption issue (someone was stomping on our variables) and totally unrelated to the performance counter. The site you listed had a very good discussion about timers though so I'll go ahead & give you the points.

DanRollins:
QPF seems to give back the exact processor speed period: i.e. 399,070,000 on our 400MHz machines.

jemax:
My bad. That variable should have been i64TicksPerMiliseconds.

Thanks for all the input!