Anyone having issues with Dual Core CPUs and timers?

Started by
23 comments, last by e-u-l-o-g-y 17 years, 7 months ago
I have a dual core cpu and my timer works fine until I move around a bit and then it goes crazy? I not sure where to start with this. I am using the following functions QueryPerformanceCounter(&framedelay); QueryPerformanceFrequency(&tickspersecond); Thanks
Advertisement
I believe it's because both cores return a different value for the timer.
There are tones of posts about this ever since the AthlonX2 cores came out.

The problem is the two cores have seperate clocks, so using the high performance counters will cause errors, as each core
returns a slightly different value.

There are several fixes.
-Some people manage to get the patches from AMD and MS to work. (I didn't :( ) These are the new drivers for cool-and-quiet and a patch for QPC.
-You can force the thread that is runnning the timing code to run on only one core by setting the affinity of that thread to only the first CPU.
-You can get a program like WinlauncherXP, and use it to force the afinity for you(good for retail programs that have problems, like COD2).
You can force the thread that is runnning the timing code to run on only one core by setting the affinity of that thread to only the first CPU.

This sounds good, but I have never done this before. So is there some function call for this? e.g. SetProcessorAffinity() GetProcessAfinity()?

thanks
Check out SetThreadAffinityMask.

I've never used it, but I've seen it before.
There's also SetProcessAffinity(), which locks the affinity for an entire process.

However, the right solution is to get the patches from MS and AMD to work. I had no problems with that, and I don't know anyone who did, so it's clearly possible.

QueryPerformanceCounter() is intended to be the reliable, bug-free, cheap counter you can use, now that RDTSC is discouraged. The continual bugs with that call (first the jump-ahead-4-seconds bug, then the jump-ahead-1.3-seconds bug, and now the dual-core bug) is doubly unfortunate.

enum Bool { True, False, FileNotFound };
for a game use a different method of querying the number of ticks under windows
iirc something like either
timeGetTime()
getTickCount();

theres no need for such a high resolution timer (this is only needed if u wanna test a func etc + see how long it takes)
When one runs into these sorts of problems, it can be most beneficial to check the Help and Support section of MS's site. Upon searching, I've come across the following two pages:

http://support.microsoft.com/kb/327809/en-us

http://support.microsoft.com/kb/909944/en-us

And yes, this is a well known issue.
Well I tried the __int64 variable and still a no go. One of the MSDN posts said to use __int64...

	__int64 tickspersecond;	__int64 currentticks;	__int64 framedelay;void Timer::Init(float tfps){	targetfps = tfps;	QueryPerformanceCounter((LARGE_INTEGER *) &framedelay);	QueryPerformanceFrequency((LARGE_INTEGER *) &tickspersecond);}void Timer::SetSpeedFactor(void){	QueryPerformanceCounter((LARGE_INTEGER *) &currentticks);	//This frame's length out of desired length	//speedfactor = (float)(currentticks.QuadPart-framedelay.QuadPart)/((float)tickspersecond.QuadPart/targetfps);	speedfactor = float(currentticks - framedelay) / float(tickspersecond / targetfps);	fps = targetfps/speedfactor;	if(speedfactor <= 0)	    speedfactor = 1;	framedelay = currentticks;}


still no dice

[Edited by - MARS_999 on August 15, 2006 3:08:14 AM]
LARGE_INTEGER is essentially just a wrapper around __int64, so swapping one for the other won't help at all. You should either install the patches or use SetThreadAffinityMask to force the timer thread onto one processor.

Personally, I use the SetThreadAffinityMask method, since I know that otherwise if I release an app using QPC(), someone will complain that it doesn't work and that it's "my fault" for not fixing it somehow.

This topic is closed to new replies.

Advertisement