Is anyone here familiar with writing / using high performance timers (farther than millisecon precision)? I'm curious because I've read some different methods which all talk about being dependant on the cpus clock rate, except that pentium M computers can speed step during program execution and therefore 100 ticks could be .0001 seconds at one point and .002 seconds some other point, anyone know of a quick way to get this to be reliable on a pentium M?

Hopefully this old thread, I replied to awhile ago will help you out.

Quote:Original post by DigitalDelusion

Quote:Original post by LEET_developer
Is anyone here familiar with writing / using high performance timers (farther than millisecon precision)?

I'm curious because I've read some different methods which all talk about being dependant on the cpus clock rate, except that pentium M computers can speed step during program execution and therefore 100 ticks could be .0001 seconds at one point and .002 seconds some other point, anyone know of a quick way to get this to be reliable on a pentium M?

Well actually counting ticks instead of time does make sense you know that way you get a clock-rate independant way of measuring performance and the only remaining headache is that you still can't compare apples to oranges (or in this case diffrent processor architecutres) since they do diffrent amount of work in a cycle.

Right, the only problem with that is say if I was writing a game where all my movement is based on frametime... so I want an object to move at one meter / second. sounds easy enough, except say the first frame the cpu is running at 200mhz and the tick count for the frame is 12, so I want to convert 12 to some fraction of a second, lets say that is 1/100th for arguments sake. Then I do all my calculations and enter the next frame and the cpu is running at 1400mhz now, and takes 12 ticks again, but now this is much less... so I need a fast way of querying the cpu speed every frame.

According to MSDN (which is known to be wrong sometimes) timeGetTime() queries the windows multimedia timer, which is millisecond precision at best, sometimes goes as far as to be innacruate up to 50 milliseconds, which is unacceptable (Im actually writing a profiling tool, and I need my measurements to be predictable), I have an assembly timer writter which gets clock tick counts, which is enough precision for me :) but I want to be able to reuse this timer in a game loop for frame timings, so that it can be accurate in accordance with the profiling logs aswell...

is there a fast way to query current cpu clock rate? I guess I'd only have to do that once a frame, so it wouldn't be too bad...

I did not find any information about potential problems to do with clock speed variation in the responses above. Does someone here have any information about this? It is a very important question ... and it doesn't just relate to Pentium M's ... my Sempron based laptop dynamically changes clock speed as well.

The real question seems to be: Is the speed driving the Performance Counter dependent on the CPU speed and affected by technologies such as Speed Step, or is it independent of such things, and driven by something like a core motherboard / chipset clock?

There are additional questions about what effects overclocking and such have on the accuracy of converting the counter into seconds using the returned rate ... because we also don't know if the rate is a constant the chipset returns, that is only accurate if the settings line up with the factory specifications, or if their is a clock generator in the chipset that is 100% consistent in all situations, and therefore the timer is accurate?

any information about this would be appreciated.

Quote:Original post by LEET_developer
Right, the only problem with that is say if I was writing a game where all my movement is based on frametime... so I want an object to move at one meter / second. sounds easy enough, except say the first frame the cpu is running at 200mhz and the tick count for the frame is 12, so I want to convert 12 to some fraction of a second, lets say that is 1/100th for arguments sake. Then I do all my calculations and enter the next frame and the cpu is running at 1400mhz now, and takes 12 ticks again, but now this is much less... so I need a fast way of querying the cpu speed every frame.

You should never use the performance counters to control your game. They are performance counters, meant for profiling the speed of your code under controlled conditions during development. Using them as program timing code would be like using repaint messages to determine user activity - it may work on some setups, but since it is not intended for that purpose it can be broken at any time.

Quote:Original post by LEET_developer
is there a fast way to query current cpu clock rate? I guess I'd only have to do that once a frame, so it wouldn't be too bad...

Even if you could query the clock rate in a way independent of the performance counters (clock tick counters) themselves, checking once per frame would not be enough. AMD's Cool'n'Quiet™ switchs even faster and more frequently then the Pentium M's 3rd generation speedstep. You would be taking one value from a fluxuating curve, which will not guarantee anything close to an accurate timing.

I was doing some research and needed very precise timing. I wasn't using a pentium though. Anyway, using windows timers i was able to get 1ms accuracy. I did quite a bit of research and really I am under the asumption that it is a pain to try to get much more accurate...Windows was never really meant to be a real time operating system.......maybe you could play with the code below and see what you get......change the delay to 1ms and make a callback function to do something....see how well this works



TIMECAPS timecaps;
timeGetDevCaps( &timecaps, sizeof( TIMECAPS ));
printf ( "The minimum peroid for logging is is %d\n", timecaps.wPeriodMin );

wTimerRes = max( timecaps.wPeriodMin, 2 );
timeBeginPeriod( wTimerRes );

wTimerID = timeSetEvent(
15, // delay in milis. - half a sec.
wTimerRes, // resolution
outputData, // callback function
NULL, // user data
TIME_PERIODIC ); // periodic timer event


// This is the timer in the function outputData
timeBeginPeriod(1);
SYSTEMTIME currentTime;
GetSystemTime(&currentTime);
timeEndPeriod(1);

Based on my experience from my experience of non-x86 systems (although I'm a software engineer I'm also involved in asic design) I would imagine that the high-perf counter is actually an RTC (real time clock) and is likely to be derived by a direct divisor from the crystal. In any system the crystal frequency is unaffected by speed-stepping (just PLL multipliers & dividers are changed and these derive from the crystal).

I don't know what the actual frequency is, but I expect that it will be in the 1-10MHz region. If you actually want to read the cycles executed try the RTSC instruction on x86 (this will of course be affected by speed-stepping).

Of course don't forget in an RTOS you won't be able to account for cycles spent in other apps during a task switch (at least not without hacking the task scheduler...)

Yeah I wouldnt use the performance counter for the frame timings, but I want the precision of that counter to be able to time my frames... if I want accurate physics and I have 4 frames in a row that are reported at 50ms, that doesnt really help me, because I know they didnt all run at the same speed, and with the inaccuracies of the windows timers, I wanted to be able to use the cycle counter in someway...

for polling the cpu speed you are right, I shouldnt do it once a frame, it should be more of a weighted average over a couple frames in different positions... and that looks like it WOULD be adding too much overhead. I guess it's back to the drawing board :)

thank you everyone for the help though, I guess for now I'll have to use my cycle counter for profiling and a windows timer for elapsed seconds..

So do you guys recommend timeGetTime() or QueryPerformanceTimer/Frequency for the elapsed time reads?