[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1182
  • Last Modified:

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?
0
Grailman
Asked:
Grailman
1 Solution
 
fl0ydCommented:
Three things to check right up:
* Did you check for the return value of QueryPerformanceFrequency? It might not be supported and return FALSE.
* Did you use LARGE_INTEGER* for your output?
* Did you divide (end - start) by the frequency?

I had a similar problem a time ago, when I used this pair of functions on an Athlon-machine -- it ran fine on any Intel machine and QueryPerformanceFrequency returned TRUE on the Athlon -- don't remember the chipset though.

If that sounds familiar to you, you might want to take a look at the 'ReaD Time Stamp Counter' processor instruction -- its asm-mnemonic is rdtsc. Check out
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=COTD-RDTSCTimer&forum=cotd&id=-1
to see how it works.

.f
0
 
GrailmanAuthor Commented:
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
0
 
DanRollinsCommented:
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
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
jemaxCommented:
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
0
 
jemaxCommented:
Please ingore the last line :)
0
 
GrailmanAuthor Commented:
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!
0

Featured Post

Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now