TR Forums

Well it looks like AMD is starting to roll out what alot have said are impossible . Story at the INQ here http://www.theinquirer.net/default.aspx?article=32790 there is also a link to the file

Well it looks like AMD is starting to roll out what alot have said are impossible . Story at the INQ here http://www.theinquirer.net/default.aspx?article=32790 there is also a link to the file

Anybody with an X2 want to post some benchmarks?

After reading that article again, something doesn't make sense... the processor is responsible for updating the timestamp counter, not the application. That instruction is just used to read, not write, the value. Why would software need to "correct" the value?

But again, we will see with some benches

Official link here:
http://www.amd.com/us-en/Processors/Tec ... 06,00.html

besides the driver it sets /usepmtimer in boot.ini that some migth already be familiar with to fix C'n'Q

It looks alot like a fix for this:
http://support.microsoft.com/Default.aspx?id=896256

I think that article is misleading. From the looks of it, this has absolutely nothing to do with R-HT.

Well tell me what benchmarks you want to see and i will try and run them . Right now I am in the middle of running benchmarks with 3D Mark 2001 . I figure its a good place to start because its almost 100% cpu bound . Yes there is a definite performance increase with the new program installed . I am keeping the numbers to myself until i have done further testing though .

just brew it! wrote:

I think that article is misleading. From the looks of it, this has absolutely nothing to do with R-HT.

At least what have been reported and speculated on. Although this R-HT thing may be completely different from what we imagined in the first place.

This looks like some timing tricks to make the OS think it is running real SMP instead of dual cores on the same die? May be Windows does not deal with dual cores properly still, with the real SMP scheduling still turning out to be a better algorithm?

Hance wrote:

Well it looks like AMD is starting to roll out what alot have said are impossible . Story at the INQ here http://www.theinquirer.net/default.aspx?article=32790 there is also a link to the file

This utility doesn't seem to be an enhancement at all, but rather 2 independent fixes. First, the /usepmtimer fix for apps experiencing audio stuttering in SMP/SMT setups, and then a fix for the games that have graphical stuttering because of the /usepmtimer fix. I don't see how this has anything at all to do with R-HT as speculated upon in the original inquirer article or the x-bit labs article.

Flying Fox wrote:

This looks like some timing tricks to make the OS think it is running real SMP instead of dual cores on the same die? May be Windows does not deal with dual cores properly still, with the real SMP scheduling still turning out to be a better algorithm?

But for all intents and purposes, dual-core is "real SMP". Something doesn't make sense here.

just brew it! wrote:

Flying Fox wrote:

This looks like some timing tricks to make the OS think it is running real SMP instead of dual cores on the same die? May be Windows does not deal with dual cores properly still, with the real SMP scheduling still turning out to be a better algorithm?

But for all intents and purposes, dual-core is "real SMP". Something doesn't make sense here.

Bitvector has mentioned it before, may be with dual core (since Microsoft counts physical sockets with their logical processor concept in their APIs), it was using the SMT scheduling policies and that is not performing properly?

Flying Fox wrote:

At least what have been reported and speculated on. Although this R-HT thing may be completely different from what we imagined in the first place.

This problem doesn't really have anything to do with R-HT though. At all. It's a timing problem that has to do with how the TSCs on a dualcore processor aren't sync'd. This can cause problems when a thread is moved from one core to another.

The crux of this really comes down to the problem that there isn't any reliable way to get a high-precision, high-accuracy timer on Windows. Depending on your windows boot switches and hardware combination the HAL might actually be using anything from the TSC to some PIC off the PCI bus on the motherboard.

Furthermore, as side issue that helps explain the situation in this thread: ttp://techreport.com/forums/viewtopic.php?p=493275, The Windows API function that microsoft suggests developers use is generally good at working things out the differences between the TSCs problem, but due to some flaws in AMD's dualcore processor implementation it still didn't work out right. That's why one of the fixes was to use the /usemptimer switch, so that Windows wouldn't use the TSCs and instead use the ACPI PM timer. This isn't as precise or accurate though. Another way to work around it would be to not use the particular power management scheme that was the primary culprit behind the drift (the C1 state)

Here's the problem that the "Dual-Core Optimizer" attempts (does?) fix: Some games just use the RDTSC instruction to read the TSC. What that means though is that, unlike the Windows API calls, there is NO accounting for the drift between the TSC should the thread move to the other core. That's clearly a problem and non-ideal.

This AMD thingie claims to sync the TSCs so that this isn't a problem. How the software actually does this, I'm not sure. Perhaps it forces the two cores to transition between states in lockstep so the drift is similiar/identical, perhaps it has some other timer match the two every now and then, perhaps both of these approaches together. Maybe something else entirely. I really don't know, and AMD doesn't really give me anything to go on other than sheer speculation.

pureevilmatt wrote:

This utility doesn't seem to be an enhancement at all, but rather 2 independent fixes. First, the /usepmtimer fix for apps experiencing audio stuttering in SMP/SMT setups, and then a fix for the games that have graphical stuttering because of the /usepmtimer fix. I don't see how this has anything at all to do with R-HT as speculated upon in the original inquirer article or the x-bit labs article.

NO. That can only affect what the windows API functions use for their timer and since this software explicitly states that it is "for those applications that bypass the Windows API for timing " that is obviously not what this utility does.

You don't have any idea what the /usepmtimer fix is/does. Stop.

The only correct thing here is where you say it doesn't have anything to do with R-HT.

Flying Fox wrote:

Bitvector has mentioned it before, may be with dual core (since Microsoft counts physical sockets with their logical processor concept in their APIs), it was using the SMT scheduling policies and that is not performing properly?

Huh?

Flying Fox wrote:

just brew it! wrote:

But for all intents and purposes, dual-core is "real SMP". Something doesn't make sense here.

Bitvector has mentioned it before, may be with dual core (since Microsoft counts physical sockets with their logical processor concept in their APIs), it was using the SMT scheduling policies and that is not performing properly?

Whoa, I said what now? AFAIK, this issue (the fix by AMD) isn't related to scheduling all. It also doesn't seem to have anything to do with R-HT.

Well, I was thinking may be Windows' scheduling policy for SMT has a bug when it comes to AMD dual core processors. Guess I was way off there. Looks like this is just a fix for AMD dual core processors. Damn may be I should not upgrade this 3200+ and go straight for a Conroe sooner? I want a build to work straight out of the box, not needing 2387 patches...

Glorious wrote:

pureevilmatt wrote:

This utility doesn't seem to be an enhancement at all, but rather 2 independent fixes. First, the /usepmtimer fix for apps experiencing audio stuttering in SMP/SMT setups, and then a fix for the games that have graphical stuttering because of the /usepmtimer fix. I don't see how this has anything at all to do with R-HT as speculated upon in the original inquirer article or the x-bit labs article.

NO. That can only affect what the windows API functions use for their timer and since this software explicitly states that it is "for those applications that bypass the Windows API for timing " that is obviously not what this utility does.

The first thing this optimizer does when you install it, is add the /usepmtimer switch to boot.ini, changing what windows precision timer bases it's value on... so despite what the AMD page says, it's not just for apps that bypass the windows timer function by using the RDTSC instruction.

The second thing it does is add a program to startup. Now, what the program does, I am uncertain, but it only runs at startup and then it immediately closes. Maybe a programmer can tell me wether or not the audio and video APIs of DirectX rely on the same timer function as windows itself?

pureevilmatt wrote:

The first thing this optimizer does when you install it, is add the /usepmtimer switch to boot.ini, changing what windows precision timer bases it's value on... so despite what the AMD page says, it's not just for apps that bypass the windows timer function by using the RDTSC instruction.

Ok, but the AMD processor driver since like 2 years ago does the same thing. This might do it too, but you should ALREADY have that switch in there. That's clearly not the purpose of this software, it is likely just included in the off-chance you didn't already have it in there.

pureevilmatt wrote:

The second thing it does is add a program to startup.

It also adds a driver, something which somehow escaped your notice...

pureevilmatt wrote:

Maybe a programmer can tell me wether or not the audio and video APIs of DirectX rely on the same timer function as windows itself?

Um, wouldn't the bigger issue be the game code? Of course DirectX uses windows API timers....

I was reading that AMD can enable Reverse-Hyperthreading via a simple BIOS update on all current AM2 X-2, can anyone confirm this?

NeRve wrote:

I was reading that AMD can enable Reverse-Hyperthreading via a simple BIOS update on all current AM2 X-2, can anyone confirm this?

No. Only AMD or the motherboard manufacturers could, we can only speculate.

http://en.wikipedia.org/wiki/Reverse_Hyperthreading

I'm not sure if this article is valid, but it states AM2's can use this function through a device driver update.

The reference to that statement is the exact same INQ article that started this thread.

It's only a stub for now. If this proves to be just smoke and mirrors I am sure they will either delete the post or update as such.

http://www.theinquirer.net/default.aspx?article=32885

Theinq finally changed story.

Reverse Hypertransport does not exist

Shintai wrote:

http://www.theinquirer.net/default.aspx?article=32885

Theinq finally changed story.

Reverse Hypertransport does not exist

Yup, that was the final nail in the coffin that we were all waiting for.

Shintai wrote:

Reverse Hypertransport does not exist

Uh, wasn't it called Reverse Hyperthreading?

bitvector wrote:

Shintai wrote:

Reverse Hypertransport does not exist

Uh, wasn't it called Reverse Hyperthreading?

Yep, even that they cant get right

I just copy/pasted their subject.

It's Fudo, what can you expect?

Now, so what is CMT from the Intel side then? Something like this dream, or just a cooling technique? I guess this should go another thread then.

Flying Fox wrote:

It's Fudo, what can you expect?

Now, so what is CMT from the Intel side then? Something like this dream, or just a cooling technique? I guess this should go another thread then.

Hehe, cooling technique for CMT sounds like the most reasonable explanation for the time being. Its obviously not some kind of RHT
And CMT is already tested, same performance and such. But ofcause, thermal testing aint done.

shintai wrote:

And CMT is already tested, same performance and such. But ofcause, thermal testing aint done.

and you have evidence of this?

Glorious wrote:

shintai wrote:

And CMT is already tested, same performance and such. But ofcause, thermal testing aint done.

and you have evidence of this?

Where do you think I got the Bios screenshot from

And we already had this on page 5 once, where you basicly right away made sure it couldn´t be argued with you. because it could be faked picture, not do anything or the like.

So why do you even ask when you disregarded it completely in the first place...

Glorious wrote:

maybe because:

1. Enabling it doesn't do anything unless it's actually used
2. That picture is inauthentic
3. The BIOS option doesn't actually set anything

or any number of reasons?

shintai wrote:

Where do you think I got the Bios screenshot from

Actually, I have no idea. Why? Because you never told us. You have a *picture* on page 5 whose origin I don't even know. If you think that's a test I don't think we speak the same language.

I "disregarded" it because enabling something in the bios doesn't mean it's truly and actually enabled nor does it mean it's actually being used.

Just thought I'd post this link here

http://theinquirer.net/default.aspx?article=32885