Valencia and 16-core Interlagos are based on Bulldozer!

[kaa]

SW solutions like AOD are not the same, and inherently inferior to, HW capabilities that are intrinsic parts of the die which the manufacturer has designed, manufactured and test for.

isn't intel's turbo clocking done by bios settings? and isn't the bios basically software?

As MU-Engineer has correctly noted, Intel's TB is a built in by Intel part of each Nehalem die.

Basically, Intel extended their variable CR controls to include the ability to speed up as well as slow down core CR.
Intel is going to both raise the maximum CR that can be attained as well as make such capabilities more fine grained (tweaking the CR of individual Functional Units instead of whole cores or dies is the ultimate goal.)

Variable CR used to just an important part of power and TDP controls. Now it's evolving into another way to enhance performance (particularly for runs of instructions that are not amenable to much parallel processing) as well.

[hyc]

Of course, unofficial patches to do the same thing for Linux powernow-k8 driver have existed for a couple of years, but the driver maintainer (who I recall is an AMD employee) always rejects them, saying AMD won't allow warranty-invalidating code to go into the mainline driver.

[kaa]

Of course, unofficial patches to do the same thing for Linux powernow-k8 driver have existed for a couple of years, but the driver maintainer (who I recall is an AMD employee) always rejects them, saying AMD won't allow warranty-invalidating code to go into the mainline driver.

People seem to keep missing the point.

NO SW METHOD OF DOING THIS IS ANYTHNG BUT A HACK.

THE ONLY PEOPLE WHO CAN DO THIS LEGITIMATELY (ie without it being overclocking) ARE THE ORIGINAL MANUFACTURERS AND IT MUST BE DONE IN HW AND ON DIE.

Any deviation from the above guidelines makes it overclocking.
Overclocking is the domain of a fringe group of HW enthusiasts who do not mind the risks involved.
OC is not for the general public; and certainly not for serious business customers.

[duby229]

Hold on wait a minute.......

So what your saying is that it's not overclocking if Intel does it in hardware with overdrive and is enabled or disabled by software in the bios or operating system it is not overclocking. But on the other hand if AMD does it in hardware with CnQ and is adjusted in the bios or software (in this case using a patched powernowd driver) then it is overclocking?

CnQ is definitely a hardware implementation. And just like every other hardware in every other modern operating system it too requires a driver. In Linux that driver is called powernowd. If a patch exists to give this hardware the same capability that Intel uses then why in the hell wouldnt you put it on the same playing field?

That definitely sounds like a double standard to me.... I think it is pretty simple to understand that if its over factory clock then its overclocked

[kaa]

If anyone sells a die that is rated for clock rate "t" at faster than "t", they are selling an OCed die. No matter who they are.

If one takes a die rated for CR "t" and gooses it to run, by any method, at higher than that, it is by definition an OCed die while so running.

That's !NOT! the case with Nehalem.

Nehalem was =designed from the ground up= to have a variable CR that included CR increases as well as decreases away from it's "baseline" CR.

Designed. Implemented as an inherent feature of the die. Tested and certified by Intel to run at even its highest CR.

TurboBoost is not OCing.
It's a new, and standard, feature of Intel dies that is as trustworthy as OCing is not.

[duby229]

So now Intel is selling underclocked chips at a premium? So instead of advertising there chips at the top certified frequency and selling them as such, they falsely advertise the certified frequency at some lower value and then claim that turboboost does something special?

What your saying is that Intel designed a chip to run at a certain frequency, but is configured to run at some lower frequency except for when turboboost is enabled and running in which case it runs at some higher frequency, but only when there is load on the CPU... Right so far?

Tell me how in the hell is that any different from CnQ? The only difference I can think of is that AMD actually advertises the top certified frequency right on the box when you buy it, which in my humble opinion is MUCH preferred. I would think it is a great idea to know from jump street what the guaranteed frequencies are before I buy.

[kaa]

Evidently you are still not understanding the concept of TurboBoost.

You need to rethink your concept of clock rate.

1st generation of CR, we had dies that ran at =a= CR.
2nd generation of CR, we had dies that ran at a baseline CR but could also run at lower CR to conserve power.
3rd generation of CR we have dies that run at a baseline CR but can also decrease that CR to conserve power =or= increase CR for a performance boost when there is thermal headroom available (due to there being low utilization of on die transistors at the baseline CR).

This "sprint mode" is not the same as the baseline CR for the simple reason that the die could not run consistently at the sprint CR and stay within the die's power or TDP ratings. Nor could the die run at the sprint CR if the die was already using enough transistors at baseline CR to be close to its TDP rating.

We can't get enough done at the "resting" or "sleeping" CRs
We can't afford to run the dies at the "sprint" CR if enough of its transistors are already pushing their limits.
We can't afford to indefinitely run the die at the "sprint" CR because the die would overheat and because such operation ages the die faster.

Intel is not selling underclocked Nehalems. They are not falsely advertising the certified frequency of any Nehalem. TurboBoost =does= do "something special". That everyone in the industry is going to also be doing in short order.

Just as we have sleeping, resting, mildly busy, working, and maximum effort metabolic rates, so to are CPU dies evolving toward such behavior.

TurboBoost is not a scam. It's a whole new approach to getting better performance out of CPUs under low IPC conditions.

[Lem]

Well, Kaa beat me to it.

However one point I was going to make, reiteration actually.. the Anandtech article I linked to earlier in this thread showed a Nehalem with stock HSF, in a closed case, with a Radeon HD4870, where TurboBoost never engaged (no thermal headroom).

So that begs the question, how often does Turbo really engage? Any i7 owners here care to comment? .. $ilent$uicide?

[Hans de Vries]

People seem to keep missing the point.
NO SW METHOD OF DOING THIS IS ANYTHNG BUT A HACK.

AMD's 65nm Griffin already has an on board micro controller for power control
and so does its successor the 45nm Regor.

Istanbul has (as far as I know) a serial bus which allows a micro controller in
the chip-set to read the temperatures and to control the power of the entire
multi-processor / multi-socket system, which has to be done from a central
position.

I find it hard to believe that AMD could have overlooked any trends with
all the work they have put into this already but we'll have to wait and see...

Regards, Hans

[kaa]

Hans, I don't think AMD has overlooked TurboBoost. For one thing, I think it's in Bulldozer.

As I said,

TurboBoost =does= do "something special". That everyone in the industry is going to also be doing in short order.

Just as we have sleeping, resting, mildly busy, working, and maximum effort metabolic rates, so to are CPU dies evolving toward such behavior.

TurboBoost is not a scam. It's a whole new approach to getting better performance out of CPUs under low IPC conditions.

IMHO, this is how all that research on having both faster CR functional units or cores and slower ones on the same die is probably coming to the x86 marketplace.

[abinstein]

You are not understanding turbo mode and its technology correctly.

The mechanisms used to adjust clock rates in turbo mode, the ones that you so much tout to be "in hardware," are all implemented in Deneb and even Agena. The only difference is an on-die thermal detector which in Intel's case allow the processor to overclock itself automatically under the condition that the thermal detector makes no objection.

However, on the flip side, that also means that under insufficient cooling, a Core i7 will silently underclock itself, basically the reverse of the turbo mode.

So Intel went the extra mile to offer an aggressive feature which allow good performance under optimal benchmarking environment. AMD, OTOH, stay conservatively at guarantee performance. That's the difference between CnQ/AOD and Turbo mode.

[kaa]

You are not understanding turbo mode and its technology correctly.

The mechanisms used to adjust clock rates in turbo mode, the ones that you so much tout to be "in hardware," are all implemented in Deneb and even Agena. The only difference is an on-die thermal detector which in Intel's case allow the processor to overclock itself automatically under the condition that the thermal detector makes no objection.

However, on the flip side, that also means that under insufficient cooling, a Core i7 will silently underclock itself, basically the reverse of the turbo mode.

So Intel went the extra mile to offer an aggressive feature which allow good performance under optimal benchmarking environment. AMD, OTOH, stay conservatively at guarantee performance. That's the difference between CnQ/AOD and Turbo mode.

B'zzt! Wrong.

Unless you show me proof otherwise, as I write this the only x86 compatible which is explicitly designed to dynamically =increase= its CR away from baseline as well as dynamically decrease it away from baseline is Intel's Nehalem.

In addition, at this point =any= x86, by AMD or Intel, "under insufficient cooling" =or= not doing much "will silently underclock itself".
THAT"S THE WHOLE POINT OF UNDERCLOCKING FEATURES.

AOD is OC because the dies it is being used on are not explicitly designed and certified to "sprint" at the CR it makes dies run at.
TurboBoost is not OC because the dies =are= designed and certified to do such sprinting dynamically.

It's that simple.

[abinstein]

Unless you show me proof otherwise, as I write this the only x86 compatible which is explicitly designed to dynamically =increase= its CR away from baseline as well as dynamically decrease it away from baseline is Intel's Nehalem.

The question is: what is your "baseline"?

For processor clock rates, the "baseline" is merely a man-made number, nowadays depending primarily on rated TDP. For example, AMD could have made the "baseline" clock rate of Phenom II 905e 3.0GHz instead of 2.5GHz, but doing so will violate its low TDP of 65W.

Since "baseline" is a line with an artificial height, it is pointless to claim a value being above or below that line. What is important is precisely, as I have said, the thermal envelope. Nehalem attempts to go over its rated TDP per core while Phenom does not.

In addition, at this point =any= x86, by AMD or Intel, "under insufficient cooling" =or= not doing much "will silently underclock itself".

AFAIK, AMD processors doesn't thermally throttle itself reliably. I do own an MSI board which underclocks the CPU and emits warning beeps when my Phenom was overheated (fan got blocked).

OTOH, Intel processors and particularly Nehalem will underclock itself when core temperature is too high. As I said, it's as simple as reverse Turbo mode. It's really not a bad thing, though, rather a safety guard. The problem, if any, is that if such capability is built-in on the processor, then user might not be aware of it while it is happening without motherboard/BIOS support.

AOD is OC because the dies it is being used on are not explicitly designed and certified to "sprint" at the CR it makes dies run at.
TurboBoost is not OC because the dies =are= designed and certified to do such sprinting dynamically.

Intel gives a much looser TDP guarantee than AMD. This makes it easier for Intel to test & bin processors with higher (estimated) TDP, then downclock them to sell as lower (estimated) TDP parts.

It is clear that Intel's processors are built for benchmarking. It gives loose TDP guarantees with built-in thermal sensors. When benchmarked under excellent cooling, the processors will sprint above the rated clock speed and give great performance. But you really don't know how well they will run in real world datacenters or cluster rack scenarios if the heat sinks and cooling are not as ideal as those used in the benchmarking, then the processors may not sprint and may even throttle themselves autonomously.

[kaa]

*sigh* just go work for AMD marketing already and stop pretending you are an objective engineering professional Abinstein.

You are full of it. Given the education you claim, you should know you are full of it. And you persist in attempting to mislead people away from objectivity and toward being AMD cheerleaders.

You are misusing your professional skills in order to shill for AMD and I dearly hope that someday I get to call you on it f2f in front of as many other members of our profession as possible.
(Shilling isn't the problem. Claiming to be objective while shilling =IS=. Just admit you're biased and not an objective professional and I'll have no problem.)

I'm done here.

[skrubol]

You are full of it.

Funny, reading this conversation that's exactly what I was thinking! I was thinking Kaa is full of crap...
I don't get what the difference between hardware and software is when it comes to overclocking. Anything that can be done in hardware (digital domain,) can be done in software and vice versa. I would guess, even the Intel stuff is still being done by software (firmware if you'd prefer,) held in flash or ROM and maybe run by a processor other than a CPU.
Are there advantages to this over CnQ? Absolutely. Software hanging can't trip it up for one. It can respond faster, etc.
It's not magic though. It could probably be implemented with a $.29 microcontroller...

Or maybe Intel has captured some clock faeries and trapped them under the heatspreader.

[Hans de Vries]

Unless you show me proof otherwise, as I write this the only x86 compatible which is explicitly designed to dynamically =increase= its CR away from baseline as well as dynamically decrease it away from baseline is Intel's Nehalem.

But that's the whole question which plays here. Can AMD bring out something similar
with the current product line or with upcoming chip-sets. AMD was actually first with
the implementation of an on die power microcontroller in Griffin.

Certifying a processor for higher frequencies is something which AMD can decide
to do anytime of course, that's not the issue. The questions are about the possible
technical implementations: On die micro controller. Micro controller in the chip-
set via APML(?) Or in Hypervisor mode by the processor itself?

Regards, Hans.

[AussieFX]

You are full of it.

Funny, reading this conversation that's exactly what I was thinking! I was thinking Kaa is full of crap...
I don't get what the difference between hardware and software is when it comes to overclocking. Anything that can be done in hardware (digital domain,) can be done in software and vice versa. I would guess, even the Intel stuff is still being done by software (firmware if you'd prefer,) held in flash or ROM and maybe run by a processor other than a CPU.
Are there advantages to this over CnQ? Absolutely. Software hanging can't trip it up for one. It can respond faster, etc.
It's not magic though. It could probably be implemented with a $.29 microcontroller...

Or maybe Intel has captured some clock faeries and trapped them under the heatspreader.

Thankyou, finally somebody has said something sensible.

This arguing for the sake of it is rapidly driving me away from this site. Not to mention the constant personal attacks.

[hyc]

Unless you show me proof otherwise, as I write this the only x86 compatible which is explicitly designed to dynamically =increase= its CR away from baseline as well as dynamically decrease it away from baseline is Intel's Nehalem.

The question is: what is your "baseline"?

For processor clock rates, the "baseline" is merely a man-made number, nowadays depending primarily on rated TDP. For example, AMD could have made the "baseline" clock rate of Phenom II 905e 3.0GHz instead of 2.5GHz, but doing so will violate its low TDP of 65W.

Since "baseline" is a line with an artificial height, it is pointless to claim a value being above or below that line. What is important is precisely, as I have said, the thermal envelope. Nehalem attempts to go over its rated TDP per core while Phenom does not.

Agreed. The functionality you're talking about is no different than even Intel Speedstep. The difference is that instead of making the default speed the fastest allowed speed, they've made it two steps lower. Anybody with a Pentium-M can do the same thing. Anybody with C'n'Q can also do the same thing. The fact that you have to change a default on these chips to accomplish it doesn't change the fact that there's nothing unique about this feature.

[kaa]

You are full of it.

Funny, reading this conversation that's exactly what I was thinking! I was thinking Kaa is full of crap...
I don't get what the difference between hardware and software is when it comes to overclocking. Anything that can be done in hardware (digital domain,) can be done in software and vice versa. I would guess, even the Intel stuff is still being done by software (firmware if you'd prefer,) held in flash or ROM and maybe run by a processor other than a CPU.
Are there advantages to this over CnQ? Absolutely. Software hanging can't trip it up for one. It can respond faster, etc.
It's not magic though. It could probably be implemented with a $.29 microcontroller...

Or maybe Intel has captured some clock faeries and trapped them under the heatspreader.

*sigh* Nope.

How about "TurboBoost is an intrinsic feature of Nehalem which changes both CR and voltage levels dynamically with a responsiveness and speed that it is IMPOSSIBLE to accomplish via any off-die (or non-manufacturer "add on") technology."

Seriously guys, I am =not= overwhelmed by Intel's TB. But it =is= very much a different beast than anything else yet done by a CPU manufacturer (and anything done by someone else doesn't count because it is by definition going to result in a die running outside manufacturer's specs and is therefore OC.)

Such built-into the die capabilities to change CR (and anything else that need to be changed to support that change) goes =way= beyond just adding a BIOS hack or a microcontroller to a mainboard.

Sorry if some of you think I'm trying to BS you. But I really am telling you nothing but the unvarnished truth.

Built in on die manufacturer support for dynamic sprint modes like TB really is a big deal. Not so much for how much TB accomplishes in and of itself, but because of what TB foreshadows for near term x86 designs.
(Think back to what I was saying about P-M when it first came out and how C2 grew out of P-M)

[AussieFX]

"Sigh"
How about you quit with the intel spin....it's sickening.

[kaa]

Unless you show me proof otherwise, as I write this the only x86 compatible which is explicitly designed to dynamically =increase= its CR away from baseline as well as dynamically decrease it away from baseline is Intel's Nehalem.

But that's the whole question which plays here. Can AMD bring out something similar
with the current product line or with upcoming chip-sets. AMD was actually first with
the implementation of an on die power microcontroller in Griffin.

Certifying a processor for higher frequencies is something which AMD can decide
to do anytime of course, that's not the issue. The questions are about the possible
technical implementations: On die micro controller. Micro controller in the chip-
set via APML(?) Or in Hypervisor mode by the processor itself?

Regards, Hans.

For the kind of dynamic CR changes a sprint mode like TB provides to work, it =must= be an instrinsic, designed in from Day One, feature of the die.

Just as our body dynamically changes heart rate, BP, Blood sugar levels, etc to adapt to the "load" the "host" is presently under.

No external system can make such changes responsively enough or with enough sensitivity for mammals.
Same story for the degree and kind of control needed to properly implement dynamically changing CR for the transistors on a IC die.

[kaa]

"Sigh"
How about you quit with the intel spin....it's sickening.

Making sure everyone understands correctly what something is does not in any way fit the definition of "spin".

For any company.

[skrubol]

Just as our body dynamically changes heart rate, BP, Blood sugar levels, etc to adapt to the "load" the "host" is presently under.

No external system can make such changes responsively enough or with enough sensitivity for mammals.
Same story for the degree and kind of control needed to properly implement dynamically changing CR for the transistors on a IC die.

If you knew how to build a mammal, it would be less than trivial to build an external system to regulate their body functions.

AMD and Intel know how to build a CPU... AMD didn't think there was demand for good dynamic overclocking (that would outweigh the backlash such a feature would get if AMD brought it to market first.)

I think such a feature could be added in a minor tweak (Ph to Ph2 for instance) if it was desired. It doesn't seem to require inputs that require it to be 'intrinsically' designed in from day 1.

[abinstein]

Lets take a slightly different point of view and ask what would it take for AMD to implement "Turbo Mode"? What mechanisms are missing?

I'd like to borrow a picture that I post in another thread about the P-states of two Phenom II CPUs:

AMD_PhenomTPD_940_905e.jpg (130.04 KiB) Viewed 310 times

Current generation of AMD family 10h processors can have up to 5 P-states, although it's possible to use an extra model specific register to support total 6 P-states. Most processors, like the two above, support only 4 P-states, so it's possible to add 2 extra P-states on "top" of the current P0 (max).

If I understand correctly, current CnQ works roughly this way. The software reads from CPU cores about the load of the cores and the NB. The software then set the next desirable P-state according to a preset policy. The is performed periodically.

For AMD to implement something like the Turbo mode, two extra things are needed. (1) An on-die thermal sensor that accurately detects core temperature. (2) The "reverse" CnQ driver that set target P-state to ones that are above the default max. According to AMD's latest revision guide, the thermal sensor problem in Phenom is already fixed in the Phenom II revision, so requirement 1 is met. What is needed is then BIOS/driver support for one or two extra P-states above the current default maximum.

Implemented correctly, it should be as reliable as the CnQ (probably more reliable than Intel's Turbo Mode). I suppose AOD/3 is already doing something similar. We know how good AMD's CnQ is, and how easy it is to active/support it. I really don't see such "self-overclocking" is much a big deal.

[Hans de Vries]

For the kind of dynamic CR changes a sprint mode like TB provides to work, it =must= be an instrinsic, designed in from Day One, feature of the die.

Just as our body dynamically changes heart rate, BP, Blood sugar levels, etc to adapt to the "load" the "host" is presently under.

No external system can make such changes responsively enough or with enough sensitivity for mammals.
Same story for the degree and kind of control needed to properly implement dynamically changing CR for the transistors on a IC die.

I don't know about blood sugar levels and heart beat rates of processors,
but as long as we are talking about the frequency change rates of PLL's.
Voltage change rates or the temperature change rates at various locations
of the die, then we are talking about processing times which are rather
slow for a decent micro controller on a 45nm or 55nm die.

Note that Istanbuls can be controlled remotely from a central point via the
Advanced Platform Management Link. It's better to do those things from
a central point anyway rather then to depend on individual processors
which have no knowledge about what is going on in neighbor sockets.

Regards, Hans