Problem with QueryPerformanceCounter()

Posted on 2002-03-19
Last Modified: 2007-11-27
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?
Question by:Grailman

Accepted Solution

fl0yd earned 200 total points
ID: 6882132
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
to see how it works.


Author Comment

ID: 6883007
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:

        reinterpret_cast<LARGE_INTEGER *>(&i64Freq)))
   i64MSPerSec = i64Freq / 1000;

        reinterpret_cast<LARGE_INTEGER *>(&i64Start)))

        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.

LVL 49

Expert Comment

ID: 6884354
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
Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.


Expert Comment

ID: 6884368
__int64 i64MSPerSec;
       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;

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

Expert Comment

ID: 6884382
Please ingore the last line :)

Author Comment

ID: 6886480
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.

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

My bad. That variable should have been i64TicksPerMiliseconds.

Thanks for all the input!

Featured Post

Master Your Team's Linux and Cloud Stack

Come see why top tech companies like Mailchimp and Media Temple use Linux Academy to build their employee training programs.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

This article will show you some of the more useful Standard Template Library (STL) algorithms through the use of working examples.  You will learn about how these algorithms fit into the STL architecture, how they work with STL containers, and why t…
Many modern programming languages support the concept of a property -- a class member that combines characteristics of both a data member and a method.  These are sometimes called "smart fields" because you can add logic that is applied automaticall…
The viewer will be introduced to the technique of using vectors in C++. The video will cover how to define a vector, store values in the vector and retrieve data from the values stored in the vector.
The viewer will be introduced to the member functions push_back and pop_back of the vector class. The video will teach the difference between the two as well as how to use each one along with its functionality.

773 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question