Our ReVolt Pub

Posted: **04 Feb 2010, 22:36**

I've heard about a bug called 'tuxabug', and the way it mess with timers.

I have a few questions, like: When does it appear? Has it been nicely corrected? Etc.
Can someone help me a little by making a short summary about this bug?

And also, does anybody still suffer from it?
> In the latter case, is someone with this issue ready to help in case I need a beta tester?

Posted: **05 Feb 2010, 00:02**

It happens with:

- Intel multi-core / multi-CPU setups
- Typically when the time goes past some threshold, 1.5 minutes - 2 minutes, I forget the exact value, it resets to zero.

I used to have a dual-celeron computer, and in that machine it happened around 9 minute mark. So the situation is much worse nowadays.

I analyzed the problem many years ago from the sources, and as far as I could figure it was because Re-Volt is using for its timer functions 32-bit values, yet the APIs are using 64-bit values.

Well, hopefully that's of some help. Fixing this bug would be huge. I bought an AMD CPU precisely to avoid this bug so it may be I can not be of help in testing. Unless it occurs in non-compatibility mode, I don't remember if it was the case.

Posted: **05 Feb 2010, 02:36**

I only had this bug myself when I joined another players game, and even then it wasn't that often (then again, I ain't racing online that often). I do have an Intel dual core processor and a 64bit system, but never experienced the problem myself.

Posted: **05 Feb 2010, 04:03**

Thanks, guys.

arto wrote:I analyzed the problem many years ago from the sources, and as far as I could figure it was because Re-Volt is using for its timer functions 32-bit values, yet the APIs are using 64-bit values.

Indeed, it looks like a problem of that kind, but there is things that I don't understand.
Why the 32 bit rollover would make the issue happening only on multi-core cpu? If it's linked to the number of cycle the cpu has performed, I think this value increase a least faster on a mono-core system...

And I did a little calculation (it may looks complicated/boring, but if you look right, it's quite simple):
My cpu do 2 577 282 560 cycle / seconde.
An unsigned 32 bits variable can reach at max the value 4 294 967 296.
So it would take just 1.66 seconde before a 32 bits variable is filled by the numer of cycle of my cpu.
But revolt 'shifted right' 6 times the number of cycles (ie. divide it 6 times by 2, that is to say by 64).
So it would just take 1.66 * 64 = 106 seconde (= 1min 64sec) on my cpu.
And if I wait more than 1 minute 46 seconde during a time trial race, there is no error in the time counter. And I don't understand why.

Thus I'm wondering if it's not rather linked to the fact that revolt could sometime query one core's cycles, and sometime another core's cycles, which could lead to different values.
And maybe there is really an issue with the 32 bit value, so we could have 2 bugs at the same time

-

Some questions:

Can you remember in which race mode it happens?

I've heard about the GO stuff displayed at wrong time, is it linked to that bug?

Does anybody have a multi-core system on which the bug doesn't appears?

On the contrary, does anybody have a single-core system on which the bug does appears?

Posted: **05 Feb 2010, 06:54**

Can you remember in which race mode it happens?

if i remember correctly it happens anywhere there is a timer. no stunt arena but every other mode.

I've heard about the GO stuff displayed at wrong time, is it linked to that bug?

Yes.
the other 2 questions i am unable to help with. i've a single core and i dont have a bug.

Posted: **05 Feb 2010, 07:34**

Tuxabug is named after the French player RTT-tuxator, the first
racer who used an Intel dual-core CPU.
It seems to affect Intel CPUs, but not AMD CPUs.

In online races the final race results are affected for all
even if only one player has tuxabug.

There is no known fix for this bug.

"I've heard about the GO stuff displayed at wrong time, is it linked to that bug?"
This is an XP bug, not really tuxabug.
Setting Compatibility mode to win98 fixes the winXP bug but not tuxabug.

Some people with an Intel multi-core CPU do not have this problem,
maybe their motherboard handles the timing things in a different way.

Posted: **05 Feb 2010, 08:16**

It seems to affect Intel CPUs, but not AMD CPUs.

Weird, but good to know.

In online races the final race results are affected for all
even if only one player has tuxabug.

Even weirder. But perhaps it could be a clue. Can somebody make a screenshot of that?

And can you confirm that all race mode are affected, not only online races?

There is no known fix for this bug.

You mean that all those affected are still playing with that bug?

"I've heard about the GO stuff displayed at wrong time, is it linked to that bug?"
This is an XP bug, not really tuxabug.
Setting Compatibility mode to win98 fixes the winXP bug but not tuxabug.

Ok, but too easy shortcut. The fact that compatibility mode corrects a problem doesn't mean it was a XP bug at all. IMO it rather means that it skips new restrictions just to let the old software run again.

Some people with an Intel multi-core CPU do not have this problem,
maybe their motherboard handles the timing things in a different way.

It's interesting.

What you said confirm my opinion, because I have now more and more the feeling that there is two bug:
-one due to the conversion from 64bits value to 32bits, and because the frequency of cpu has increased a lot since revolt was released, which could cause the GO stuff appears at regular intervals.
-one due to multi-core, perhaps due to te fact that revolt could sometime ask to one core and sometime to another.

But I'm just guessing, as I said, it's a feeling, I'm far from being conviced of that yet.

I won't try a lot of things about that bug, because I don't own a multi-core, and I think that, as arto said, fixing this bug would be huge.

But if someone has this bug and can give me more precise details about it, like the system he use, when it exactly occurs, in which conditions, etc., it could help anyhow.

Posted: **05 Feb 2010, 10:18**

For many years I used an Intel multi-threading CPU, while it was
not a dual-core CPU Revolt read it as such and gave me the
tuxabug. I fixed this with a program that turned of one half
of the multi-threading when Revolt was running.
I now use an AMD dual-core CPU with no problems

Tuxabug only affects the Race Results of online games, no other
mode (I think). If 8 players are racing and one of the players has tuxabug
and comes in last place, the race result will show him in first place
with an incorrect total race time, sometimes a strange time like 2 seconds.
This will display to all players. This happens when the total time is over
about 2 mins (the longer tracks).

We are talking here of two bugs:
Tuxabug caused by most Intel multi-core CPUs
and the winXP bug (The GO! thing acting funny and the lap time
resetting after a certain amount of time in all modes).

The winXP bug can be fixed with win98 Compatibility mode.
I am not sure if there is any fix for tuxabug.

Posted: **05 Feb 2010, 10:53**

hilaire9 @ Feb 5 2010, 05:48 AM wrote:This will display to all players.

Ah, ok. First time I understood that all players have their time affected, but it's just the display of the 'tuxabuged' player time that is affected for all all other players.

I was working hard on this bug. At the end, I was able to create the GO bug on my system, which normally don't suffer from it (it was wilful, of course

). It means I could be hopefull to be able to correct this one.

But if tuxabug is really different from GO bug, then I really don't know what more I can do. Perhaps someone can send me a multi-core system to help debugging...

I think it's the only solution, don't you?

The thing I don't understand is why using multi-core gives a bug, since except on loading, revolt uses only one thread (that is to said, one core, I presume).
That could make me change my mind about the multi-core possibility of bug of which I talked about in the previous post... But the fact is I don't see other possible cause.

Posted: **05 Feb 2010, 21:14**

jigebren @ Feb 5 2010, 06:23 AM wrote: The thing I don't understand is why using multi-core gives a bug, since except on loading, revolt uses only one thread (that is to said, one core, I presume).
That could make me change my mind about the multi-core possibility of bug of which I talked about in the previous post... But the fact is I don't see other possible cause.

I think it is multi-core related. If I remember correctly, with quad-core it happens faster than with dual-core (someone could confirm this).

I don't really understand why it happens. Intuition would claim that it is because with dual/quad-cores there's more ticks per second so the 32-bit counter overflows faster. But I have vague memory that I couldn't confirm this from looking at the sources.

I remember I looked at the Windows API that is used to get the value also, but didn't see in the documentation anything that would explain why that would happen.

Posted: **05 Feb 2010, 21:29**

arto @ Feb 5 2010, 04:44 PM wrote:I don't really understand why it happens. Intuition would claim that it is because with dual/quad-cores there's more ticks per second so the 32-bit counter overflows faster.

Weird, I would have intuit the opposite (Unless all core 'ticks' are added), because precisely I thought the number of core allows to have increased power without using higher frequency.

In the API doc, there is something that could be related to that:

API wrote:On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.

But I can't try anything without a multi-core system.

Another thing, do we see this bug randomly, or does it seems to appear a regular interval, like the GO bug?

Posted: **05 Feb 2010, 22:26**

jigebren @ Feb 5 2010, 04:59 PM wrote:
arto @ Feb 5 2010, 04:44 PM wrote:I don't really understand why it happens. Intuition would claim that it is because with dual/quad-cores there's more ticks per second so the 32-bit counter overflows faster.
Weird, I would have intuit the opposite (Unless all core 'ticks' are added), because precisely I thought the number of core allows to have increased power without using higher frequency.

That's what I thought, that they are added together.

Another thing, do we see this bug randomly, or does it seems to appear a regular interval, like the GO bug?

It's regular and happens always at the same time point.

Posted: **05 Feb 2010, 23:25**

Oh, and jigebren, see this older topic on this issue: http://z3.invisionfree.com/Our_ReVolt_P ... wtopic=202

Posted: **06 Feb 2010, 00:52**

arto @ Feb 5 2010, 05:56 PM wrote:It's regular and happens always at the same time point.

A thing like that would make me think it's quite the same bug than GO bug. I'm a bit confused, now...

And thanks for the link arto. The microsoft support page resume some stuff we said, but in an official way.

I still don't understand why in this case some people can stil use hyperthreading with >2GHz cpu without suffering from his bug. Maybe in their case, the compatibility mode was able to help.

EDIT: Oh, and we talk about 'Tuxabug', but it seems that the correct term is 'bugatux'...

-

Now, it's a call to all members here, who read this topic but don't use to answer. Can you please just answer something like this, replacing values in [] with your values:

Code: Select all

I have a &#91;2.0&#93;GHz &#91;AMD/intel&#93; cpu with &#91;1&#93; cores &#91;with/without&#93; hyperthreading. I &#91;do/don't&#93; have the bugatux bug. I &#91;do/don't&#93; have the GO GO bug. I &#91;do/don't&#93; use win98 compatibility mode.

It won't take a lot of your time, and it can help me from losing a lot of mine.

Posted: **06 Feb 2010, 02:36**

Code: Select all

I have a &#91;1.0&#93;GHz &#91;Intel&#93; cpu with &#91;1&#93; core &#91;without&#93; hyperthreading. I &#91;don't&#93; have the bugatux bug. I &#91;don't&#93; have the GO GO bug. I &#91;don't&#93; use win98 compatibility mode.

FYI I don't use win98 compatibility mode as I use winME which is basically a tweaked win98. My PC is about 10 years old now.

Posted: **06 Feb 2010, 02:45**

WinME, the worst windows ever

You're not lucky, manmountain.
And even if cpu<2GHz won't help me much, thanks for the answer.

Posted: **06 Feb 2010, 04:07**

jigebren @ Feb 5 2010, 10:15 PM wrote:WinME, the worst windows ever You're not lucky, manmountain.

Tell me about it!

I am reluctantly using winME as win98 did not support my cable modem, otherwise I would still be using win98.

I will not upgrade unless my PC goes up in flames.

Posted: **06 Feb 2010, 07:35**

Manmountain, if your PC goes up in flames run from your
house, do not run back in and try to save it!
May I suggest winXP for your new computer.

Posted: **06 Feb 2010, 11:27**

Code: Select all

I have a &#91;2.4&#93;GHz &#91;Intel&#93; cpu with &#91;2&#93; cores &#91;without&#93; hyperthreading &#40;I think&#41;. I &#91;don't&#93; have the bugatux bug. I &#91;don't&#93; have the GO GO bug. I &#91;do & don't&#93; use win98 compatibility mode.

Posted: **06 Feb 2010, 11:32**

jigebren @ Feb 5 2010, 08:22 PM wrote:
arto @ Feb 5 2010, 05:56 PM wrote:It's regular and happens always at the same time point.
A thing like that would make me think it's quite the same bug than GO bug. I'm a bit confused, now...

And thanks for the link arto. The microsoft support page resume some stuff we said, but in an official way.

I thought they're the same too, but I guess what makes them different is that on some systems the GO bug can be solved with compatibility mode but the tuxabug can not. I think the underlying cause maybe the same nevertheless.

I still don't understand why in this case some people can stil use hyperthreading with >2GHz cpu without suffering from his bug. Maybe in their case, the compatibility mode was able to help.

Yes, I think so. Seems AMD processors work with compatibility mode, but Intel ones suffer about it even with compatibility mode on. I suspect it may be because AMD doesn't have hyperthreading.

EDIT: Oh, and we talk about 'Tuxabug', but it seems that the correct term is 'bugatux'...

Well, like in science things have sometimes historical names, not necessary correct ones

. Anyway I've seen both used.

Code: Select all

I have a &#91;2.6&#93;GHz &#91;AMD&#93;
 cpu with &#91;4&#93; cores &#91;without&#93; hyperthreading. I &#91;don't&#93; have the bugatux bug. I &#91;don't&#93; have the GO GO bug. I &#91;do&#93; use win98 compatibility mode.

And a little clarification: Without the compatibility mode I suffer from the GO and tuxabug.

Posted: **06 Feb 2010, 20:20**

jigebren @ Feb 4 2010, 11:33 PM wrote: Thanks, guys.
And I did a little calculation (it may looks complicated/boring, but if you look right, it's quite simple):
My cpu do 2 577 282 560 cycle / seconde.
An unsigned 32 bits variable can reach at max the value 4 294 967 296.
So it would take just 1.66 seconde before a 32 bits variable is filled by the numer of cycle of my cpu.
But revolt 'shifted right' 6 times the number of cycles (ie. divide it 6 times by 2, that is to say by 64).
So it would just take 1.66 * 64 = 106 seconde (= 1min 64sec) on my cpu.
And if I wait more than 1 minute 46 seconde during a time trial race, there is no error in the time counter. And I don't understand why.

Thus I'm wondering if it's not rather linked to the fact that revolt could sometime query one core's cycles, and sometime another core's cycles, which could lead to different values.
And maybe there is really an issue with the 32 bit value, so we could have 2 bugs at the same time

Re-Volt uses these functions for the timing:

QueryPerformanceCounter
QueryPerformanceFrequency

The QueryPerformanceCounter is not necessarily the CPU cycles as far as I can gather from the doc.

Posted: **06 Feb 2010, 20:51**

A little trick for those with mutli-core processors to try:

1. Run Re-Volt.exe
2. Run Task Manager (ctrl+alt+del)
3. Open the processes tab
4. Right click on revolt.exe and select Processor Affinity
5. Unselect one of the check boxes if you have more than one selected

This may help in some way.... Let me know

Posted: **06 Feb 2010, 21:08**

arto @ Feb 6 2010, 03:50 PM wrote:Re-Volt uses these functions for the timing:

QueryPerformanceCounter
QueryPerformanceFrequency

That, I can't ignore now, after the time I spent on it.

arto wrote:The QueryPerformanceCounter is not necessarily the CPU cycles as far as I can gather from the doc.

That true, arto.
But if you take a look at the link you gave me: m$ support
You'll see that they talk about 2.1GHz cpu.
And if you take the maximum value for a 32 bit value, it's 4 294 967 295 for a signed value, but 2 147 483 647 for and unsigned value, that is to said 2.1Giga.
There is a strange similitude here with the number of cycles per second for a 2.1GHz cpu, don't you think?
Of course, that don't means ALL cpus work like that, and in that case your remark can become very true...

zagames wrote:4. Right click on revolt.exe and select Processor Affinity

Yep, I didn't know this option was so easily available for multi-core users. I was thinking about trying to find a way to set this in my future tool.

I think that, by selecting Processor Affinity and correcting the GO GO bug, there is a hope to get rid of the bugatux bug.

Posted: **06 Feb 2010, 22:15**

jigebren @ Feb 6 2010, 04:38 PM wrote:
arto @ Feb 6 2010, 03:50 PM wrote:Re-Volt uses these functions for the timing:

QueryPerformanceCounter
QueryPerformanceFrequency
That, I can't ignore now, after the time I spent on it.

arto wrote:The QueryPerformanceCounter is not necessarily the CPU cycles as far as I can gather from the doc.
That true, arto.
But if you take a look at the link you gave me: m$ support
You'll see that they talk about 2.1GHz cpu.
And if you take the maximum value for a 32 bit value, it's 4 294 967 295 for a signed value, but 2 147 483 647 for and unsigned value, that is to said 2.1Giga.
There is a strange similitude here with the number of cycles per second for a 2.1GHz cpu, don't you think?

Yes, that's too much of a coincidence... It's probably precisely the topic of MS bug article.

That said, Re-Volt seems to be using unsigned values for the timing calculations. At least by a quick glance, of course there could be related bug where that does not hold true.

But we can get quite easily some clarification to this. When I have time I'll make a program to print out my CPU's values for QueryPerformanceCounter and QueryPerformanceFrequency. And maybe that will give some idea. Of course I don't suffer from tuxabug, but I seem to remember the GO bug. If my values change by using compatibility mode that would be interesting.

Posted: **07 Feb 2010, 03:23**

arto wrote:And a little clarification: Without the compatibility mode I suffer from the GO and tuxabug.

arto wrote:Of course I don't suffer from tuxabug, but I seem to remember the GO bug. If my values change by using compatibility mode that would be interesting.

It's not 100% clear. Can you make the tuxabug appear on your system under certain conditions, or not?
In the later case, maybe I could try to make a file to send you for testing. I still have a little hope that we have to verify...

Posted: **07 Feb 2010, 13:10**

jigebren @ Feb 6 2010, 10:53 PM wrote:
arto wrote:And a little clarification: Without the compatibility mode I suffer from the GO and tuxabug.

arto wrote:Of course I don't suffer from tuxabug, but I seem to remember the GO bug. If my values change by using compatibility mode that would be interesting.
It's not 100% clear. Can you make the tuxabug appear on your system under certain conditions, or not?
In the later case, maybe I could try to make a file to send you for testing. I still have a little hope that we have to verify...

As far as I've understood, tuxabug and the so called GO bug are indistinguishable from each other, that is their effect is the same - reset of the lap timer. That bug I can reproduce.

Posted: **07 Feb 2010, 19:33**

I did some quick tests, take these with grain of salt but might be some food for thought anyway.

The XBox sources and the original PC sources have different method of calculating the timer. The XBox version seems safe®, but if the retail Re-Volt version uses the one from the demo sources, problems may arise. In XBox version the value is shifted to lower the precision, in PC version out of the 64 bit value only the low part is considered:

QueryPerformanceFrequency(&time);
TimerFreq = time.LowPart;

If this is a large value in some CPU combinations, then overflowing seems likely.

Furthermore my tests seem to indicate that the GO bug and the tuxabug really are separate issues. At least there was no change when I ran the test with either compatibility mode or without.

Anyway here are the results:

Xbox Frequency: 55930
Xbox Counter: 439367393
PC Frequency LowPart: 3579545
PC Counter LowPart: 2349709941
PC Frequency HighPart: 0
PC Counter HighPart: 6
PC ULONG MAX / TimerFreq: 1199 secs, 19 min
PC ULONG MAX: 4294967295

I have marked the different ways Xbox version and PC version make the counts. Hope that makes sense. It was a quicky test.

One more thing, that 19 minute mark of overflow seems valid to me on my system.

Posted: **08 Feb 2010, 02:39**

I think there is a weird thing that's confusing me!
I was surprized by your value:

PC Frequency LowPart: 3579545

If I understood well, you wrote a little tool to know it. But the value seemed to me quite low.

So I took a look at the value used by revolt himself on my sytem, and I found...
3579545

In a post above , I said "My cpu do 2 577 282 560 cycle / seconde." I believe I got this value the same way...
Has it changed? (by something in windows?) Am I mistaken somewhere?
I'm quite lost for now.

Just for you to know, retail revolt version (at least 1207) use the Xbox way. It shift 6 time the QueryPerformanceFrequency() returned value (which is corresponding to what you can see in some commented part of the xbox source). I don't look at the PC sources anymore, since everytime I found out that xbox version sources version are more close to the retail PC version (if you take care of the commented parts).

Posted: **08 Feb 2010, 03:15**

jigebren @ Feb 7 2010, 10:09 PM wrote: I think there is a weird thing that's confusing me!
I was surprized by your value:
PC Frequency LowPart: 3579545
If I understood well, you wrote a little tool to know it. But the value seemed to me quite low.

So I took a look at the value used by revolt himself on my sytem, and I found...
3579545

In a post above , I said "My cpu do 2 577 282 560 cycle / seconde." I believe I got this value the same way...
Has it changed? (by something in windows?) Am I mistaken somewhere?
I'm quite lost for now.

Yes, I wrote a tool that takes the values as returned by QueryPerformanceCounter and QueryPerformanceFrequency and outputs them like they are modified by Re-Volt.

The (commented out PC version) in XBox sources shifts the bits by 6, and the demo PC version just takes the lower 32-bits of the 64-bit value.

How did you find your value?

If I've understood correctly, the frequency is just the number Counter increases every second. It's not the same as CPU cycles, even if it can be. What kind of processor you have? That you have the same exact number in Re-Volt as I do is interesting if you have totally different kind of processor than I do.

Just for you to know, retail revolt version (at least 1207) use the Xbox way. It shift 6 time the QueryPerformanceFrequency() returned value (which is corresponding to what you can see in some commented part of the xbox source).

That's good to know... in that case my timer should overflow in about 1280 minutes.

I don't look at the PC sources anymore, since everytime I found out that xbox version sources version are more close to the retail PC version (if you take care of the commented parts).

Yes, that's my experience too... this coincidence of 19 minutes just made me suspicious since I remember hitting that limit. But I've changed CPUs many times during these years so it can be a coincidence it showed that with this processor.

Posted: **08 Feb 2010, 03:24**

Is there anyone reading here who has tuxabug?

If you do, please download this program and run it:

http://rvhouse.zackattackgames.com/down ... tester.exe

Then copy paste the results here. It could give some hints for jigebren how to solve this problem!

Posted: **08 Feb 2010, 04:06**

Arto, let me tell you that being help buy you is a real pleasure.

Here is the result on my system, my cpu is a pentium 4, 2.40GHz:

Code: Select all

XBox Frequency&#58; 55930
XBox Counter&#58; 1150612290
XBox ULONG MAX / TimerFreq&#58; 76791 secs, 1279.85 min
PC Frequency&#58; 3579545
PC Counter&#58; 624743305
PC ULONG MAX / TimerFreq&#58; 1199 secs, 19.98 min
PC Frequency HighPart&#58; 0
ULONG MAX&#58; 4294967295
Press any key to exit

Notice that can help: to copy informations from arto's tool, right-click on the 'top bar' of the window, choose 'Modify\select all', then right-click on the windows and the data are copied in the clipboard.

arto wrote:How did you find your value?

By examining the value in the registers in my debugger. The highpart was 0, so I just took the lowpart. I've just made it once more to be sure. And it correspond to the value from your tool above.

I still can't remember how I found "My cpu do 2 577 282 560 cycle / seconde." I'm quite sure I did it the same way...

Posted: **08 Feb 2010, 04:21**

jigebren @ Feb 7 2010, 11:36 PM wrote:Arto, let me tell you that being help buy you is a real pleasure.

Compared to the great things you're willing to achieve and the amount of work you're putting into it for us all, I'd feel ashamed if I didn't try to help with the little I can.

Here is the result on my system, my cpu is a pentium 4, 2.40GHz:

Interesting that we have quite different systems, yet the frequency is the same. Of course this might be just the reason why AMD processors don't have tuxabug even with multi-cores. I'd really like to see someone who has tuxabug to give his results.

Posted: **08 Feb 2010, 11:53**

I don't got trouble with the tuxabug myself, so my results might not be that interesting:

Code: Select all

XBox Frequency&#58; 223721
XBox Counter&#58; 72925273
XBox ULONG MAX / TimerFreq&#58; 19197 secs, 319.95 min
PC Frequency&#58; 14318180
PC Counter&#58; 372253897
PC ULONG MAX / TimerFreq&#58; 299 secs, 4.98 min
PC Frequency HighPart&#58; 0
ULONG MAX&#58; 4294967295
Press any key to exit

Then again, the values are quite lower than Jigebren's - maybe I'm just not racing often/long enough?

Posted: **08 Feb 2010, 23:53**

There is still one thing I can't achieve to understand, here, but I didn't concentrate on this lately.

Urnemanden, can you specify what your cpu is? Brand, number of cores and speed.

Posted: **09 Feb 2010, 00:09**

Sure, here is a short overview:

Number of CPU(s): One Physical Processor / 2 Cores / 2 Logical Processors / 64 bits
CPU Full Name: Intel® Core2 Duo CPU T8300 @ 2.40GHz
CPU Name Intel: Mobile Core 2 Duo T8300
CPU Code Name: Penryn
Platform Name: Socket P (478)
Revision: M0
Technology: 45 nm
Instructions: MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, ET64, VMX, EST
Original Clock: 2400 MHz
Original System Clock: 200 MHz
Original Multiplier: 12.0
CPU Clock: 2393 MHz
System Clock: 199.4 MHz
FSB: 797.5 MHz
Core 0 Speed: 1196.3 MHz
Core 0 Multiplier: 6.0
Core 1 Speed: 1196.3 MHz
Core 1 Multiplier: 6.0
L1 Data Cache: 2 x 32 KBytes
L1 Instructions Cache: 2 x 32 KBytes
L2 Cache: 3072 KBytes

That's what SIW is telling me.

Oh, and when I boot my laptop there it says "Phoenix", but I don't know if that helps, lol.

Posted: **27 Feb 2010, 08:31**

I'm getting a headache trying to understand all things related to this bug.

I have understood one thing. I said once above "My cpu do 2 577 282 560 cycle / seconde." and after, I couldn't remember how I had found this value.

Well, if I look directly in memory at the value returned by QueryPerformanceFrequency on my system, I got (it's a 64bits value):
99 9E 36 00 00 00 00 00
which gives 3579545 in little-endian, and 2577282560 in big-endian (my previous value).

Why did I calculate it previously using big-endian, I don't know. The fact is that 2577282560 (divided 3 times by 1024) gives exactly 2.4 GHz, my cpu frequency. Very strange coincidence...

On the contrary, 3579545, which seems to be the correct value, doesn't mean anything on my system at first view.

-

@urnemanden
unless your system has been infected by the rst's tool, Phoenix is just the brand of your BIOS

.

Posted: **28 Feb 2010, 02:40**

Well, if I look directly in memory at the value returned by QueryPerformanceCounter

You mean QueryPerformanceFrequency, right?

Why did I calculate it previously using big-endian, I don't know. The fact is that 2577282560 (divided 3 times by 1024) gives exactly 2.4 GHz, my cpu frequency. Very strange coincidence...

What do you mean with exactly 2.4 GHz?

If I do those divides with Windows' calculator I get:

2,400281429290771484375

It's approximate, but it's not exact. If it really would be directly counting the clocks of the CPU, and assuming the G part is counted with multiplies of 1024, it would be exact. If it's not exact then it's just a coincidence?

Posted: **28 Feb 2010, 02:55**

I have corrected my QueryPerformanceFrequency / QueryPerformanceCounter mistake. Thanks arto.

arto @ Feb 27 2010, 10:10 PM wrote:What do you mean with exactly 2.4 GHz?

Well, I wasn't implying that it is an exact integer value. I meant that 2,400... was looking very very similar to the speed value of my cpu.
It HAS to be just a coincidence, but at first sight, it was quite weird...

And I still don't understand why my calculation to give a recommended value to be used in WolfR4 doesn't seem to work on Human's (and other) system (see the wolfR4 topic).

Posted: **28 Feb 2010, 04:31**

jigebren @ Feb 27 2010, 10:25 PM wrote: And I still don't understand why my calculation to give a recommended value to be used in WolfR4 doesn't seem to work on Human's (and other) system (see the wolfR4 topic).

Maybe someone here might have an idea if you let us know what you do with that value. I assume by the allowed values that you're doing some shifting of bits but exactly where... If you can give some pointers to the C source where you're doing the shifting I might be able to ponder the repercussions a bit.

Posted: **28 Feb 2010, 05:01**

Sorry, arto. I though you knew where it occurs it the source code. Well, here it is:

in file:main.cpp:line~719: wrote:TimerFreq = (unsigned long)(time >> TIMER_SHIFT);  //§ probably cause of 'tuxabug' here

in file:timing.cpp:line~241: wrote:return (unsigned long)(time >> TIMER_SHIFT);

The shifting was already implemented by revolt developers. What I'm trying to do is to find a better value for modern computers than the default 6.

Posted: **28 Feb 2010, 05:13**

jigebren @ Feb 28 2010, 12:31 AM wrote: Sorry, arto. I though you knew where it occurs it the source code. Well, here it is:
in file:main.cpp:line~719: wrote:TimerFreq = (unsigned long)(time >> TIMER_SHIFT); //§ probably cause of 'tuxabug' here

in file:timing.cpp:line~241: wrote:return (unsigned long)(time >> TIMER_SHIFT);
The shifting was already implemented by revolt developers. What I'm trying to do is to find a better value for modern computers than the default 6.

Yes, that was my guess but you're doing so much magical things with your program that I know better than to try guessing

.

I looked at the source and the QueryPerformanceFrequency is also used in util.cpp in figuring out the frame rate or something. Could this be the cause of the weird symptoms if you are not patching that in anyway?

Posted: **28 Feb 2010, 05:23**

arto @ Feb 28 2010, 12:43 AM wrote:I looked at the source and the QueryPerformanceFrequency is also used in util.cpp in figuring out the frame rate or something. Could this be the cause of the weird symptoms if you are not patching that in anyway?

In fact, I think that the util.cpp was added for the xbox version only. I have already searched for it, but this second call to QueryPerformanceFrequency does not exist in the compiled binary.

For example, if you take a look at the call to FrameRate_Init, you can see in the comments that is was an addition:

Code: Select all

//&#036;ADDITION - initialize framerate tracker
    FrameRate_Init&#40;&#41;;
//&#036;END_ADDITION

EDIT: Oh, and I think we have to forget about all my questions and wonders about the QueryPerformanceFrequency returned value looking like my 2.4GHz cpu clock. I now think (according to the Win SDK doc) that it's clear that the returned value is not the cpu clock value. It just has to be taken as a reference value, and that's all...
Of course still remains the question about the calculation to obtain a good shift value to be used by WolfR4.

Posted: **01 Mar 2010, 02:20**

jigebren @ Feb 28 2010, 12:53 AM wrote: In fact, I think that the util.cpp was added for the xbox version only. I have already searched for it, but this second call to QueryPerformanceFrequency does not exist in the compiled binary.

For example, if you take a look at the call to FrameRate_Init, you can see in the comments that is was an addition:
Code: Select all
//&#036;ADDITION - initialize framerate tracker
    FrameRate_Init&#40;&#41;;
//&#036;END_ADDITION

Okay, missed that one, took a real shoddy and quick look at the sources :-P.

Now I get the fastening of car effect if I put high enough value to the "Fix Go Go bug" input box. My recommended value is 8. Below 15 there is no effect. At 15 car goes fast. At 16 and higher the whole screen is choppy. At 19 and over RV just displays black screen when launched.

Of course that's not any wonder condsidering the value of my QueryPerformanceFrequency value, the precision runs out.

I'd like to see the results for human and others who experience that bug the results from the tool I posted up there. That could give some hint.

Posted: **17 Jul 2010, 02:05**

@Jig-> What exactly is different between Tuxabug and GoGo bug? Which one is fixed by changing the process affinity, which one involved revolt not using the full 64 bits to store the counter?

Jig wrote:And I did a little calculation (it may looks complicated/boring, but if you look right, it's quite simple):
My cpu do 2 577 282 560 cycle / seconde.
An unsigned 32 bits variable can reach at max the value 4 294 967 296.
So it would take just 1.66 seconde before a 32 bits variable is filled by the numer of cycle of my cpu.
But revolt 'shifted right' 6 times the number of cycles (ie. divide it 6 times by 2, that is to say by 64).
So it would just take 1.66 * 64 = 106 seconde (= 1min 46sec) on my cpu.
And if I wait more than 1 minute 46 seconde during a time trial race, there is no error in the time counter

I have a core 2 duo cpu with win7 and it has no time bugs. I installed windowsxp in virtual machine and the clock resets after 1:45 secs always. Win98 compatibility fixes it, your GoGo bugfix fixes it, but Tuxabug fix doesnt fix it. So this is the gogo bug.

But what is the tuxabug?

It is supposes to be caused by dual core/hyperthreading, irrespective of operating system (i have core 2 duo + win7, no tuxabug.. even in virtual xp, there's only gogo bug).

What makes it more confusing is, my old pc is Pentium 4 3.06GHz with Hyper-Threading. Only GoGo bug happens, no tuxabug! (fixed by compatibility and gogo bugfix).

If it's of any use.. Frequency values from your wolf log for the systems are...

Core 2 Duo 2.6GHz - Win7 : 2539140
Same PC, WinXP in Virtual Machine emulating 2 Cores: 2602270000
Same PC, WinXP in Virtual Machine emulating 1 Core, 1 Processor: 2601540000
Old Winxp pc - Pentium 4 3.06GHz HT (hyperthreaded): 3065910000

As you can see above, all winxp pcs above give the actual frequency of cpu. But the win7 pc gives the value of 2539140. That means my time will be reset after nearly 30 hours. Maybe operating systems (except winxp) themselves shift the frequency? My real frequency around 2.5 billion shifted 10 times gives 2.5 million, so i'm guessing windows7 shifts the frequency 10times, and revolt shifts 6 times, giving the actually used resolution around 42600. (and even that is about 25 micro seconds resolution!)
BTW, when i run Wolf in win98 compatibility mode in Virtual Winxp, the frequency i get is 4124041.

I think the frequency/counter thing + winxp causes Gogo bug and more than one processors cause tuxabug in some computers (god knows which computers). But maybe you can clarify the difference between the 2 bugs, and say what you did to fix each of them?

Posted: **19 Jul 2010, 03:00**

Huki @ Jul 16 2010, 09:35 PM wrote:@Jig-> What exactly is different between Tuxabug and GoGo bug? Which one is fixed by changing the process affinity, which one involved revolt not using the full 64 bits to store the counter?

To be honest, I can't really tell. At the beginning of this topic I was also asking for clarification about them.
I have none of those bugs myself, and I fixed them using info I found by reading forums, etc.

I think the frequency/counter thing + winxp causes Gogo bug and more than one processors cause tuxabug in some computers (god knows which computers).

For now, that's what I think too, and I have used the appellations accordingly.

But maybe you can clarify the difference between the 2 bugs, and say what you did to fix each of them?

About the bugs, I can't say much, but I can tell you at least what I did to fix them in WolfR4:

The Gogo bug fix modify the re-volt shifting value so that a rollover occurs once every hour only. I could have use a bigger interval, but it would have lowered the accuracy of the timer. Thus the gogo bug fix should not only fix the gogo bug, but it should also increase the timer resolution (it could be better on some sytems - mainly the most recent ones I think - to stay closer to the original re-volt).

The Tuxabug fix only modify the process affinity to force re-volt to use only the first core of the cpu.
But until now, I have not found anybody that still have this bug, so I can't ensure that the fix is actually usefull.

For info, in windows the Frequency values (the one reported in WolfR4) is not guaranteed to be the real cpu clock value. It is only guaranteed to be a constant value while the system is running.
I'm quite sure the Win98 compatibility mode can modify this value, so it is likely to fix the Gogo bug (but just likely, not cocksure I think).
And I'm also quite sure that the win98 comp. mode also set the process affinity to use only 1 core.

Posted: **19 Jul 2010, 03:13**

Does usage of only 1 core of the CPU affect the FPS any way?

Posted: **19 Jul 2010, 03:40**

From experience, it looks like all windows versions give a lower frequency value, but winxp with hyperthreaded/multicore cpu gives the real frequency of the cpu, which causes the rollover and gogo bug. So I'm just going to assume that tuxabug doesn't exist

@urne: i dont think revolt uses that much cpu to cause slowdown with singlecore

Posted: **23 Jul 2010, 03:25**

Huki @ Jul 19 2010, 03:40 AM wrote: @urne: i dont think revolt uses that much cpu to cause slowdown with singlecore

Hmm, when I have 16x Antialiasing turned on, revolt lags with win98 compatibility, but runs fine at 60fps when compatibility is turned off. Using a single core does cost performance if you are using graphics card forced settings at maximum.

Our ReVolt Pub

About Bugatux / Go Go Bug