i7 Turbo - Tool to test for Turbo throttling

[unclewebb]

i7 Turbo 6.8
http://www.fileden.com/files/2008/3/3/1794507/Turbo.zip

This tool is designed to test for Turbo throttling which can occur on some X58 motherboards when overclocking at high load levels as you approach the TDP limit of your CPU. Most motherboards allow you to turn off TDP based throttling in the bios but not all of them do and not all bios versions work correctly. If you are using the Turbo feature of a Core i7 processor, it's a good idea to make sure that your motherboard properly supports this feature.

The multiplier for a Core i7-920 is typically 20.0 and if Turbo mode is enabled, you get a +1.0 boost for a total of 21.0. With a 920, even if a bios lets you select a multiplier of 21.0 directly, internally it is still using the Turbo feature of your CPU. Turbo throttling can occur at high loads where the +1.0 Turbo boost will start to rapidly cycle on and off hundreds of times a second as you approach the TDP limit. When this first starts to happen, not all software is able to detect that your multiplier is intermittently dropping down to 20.0. Software that only samples your multiplier once per second might completely miss this problem.

There are two ways to read the current multiplier from a CPU. The typical way is to read a model specific register (MSR) within the CPU. This gives you a snapshot of what the multiplier is at that particular instant. If software only reads this value once per second then it can miss what's really going on.

The second way that Intel recommends is to compare two high performance internal timers within their CPU and then to use that information to calculate what the multiplier is.
The Intel Turbo White Paper outlines this method:
http://download.intel.com/design/pro...ots/320354.pdf

The advantage of the calculated multiplier is that during a one second sample period, it can be used to very accurately calculate the average multiplier during that interval. This method tends to be extremely precise when the CPU is fully loaded.

Unfortunately, at idle, the calculated multiplier has a tendency to wander depending on how your motherboard and C-States are set up. If your Windows power settings and C-State settings in the bios are in agreement, the amount of wander will be minimal.

Edit: If you are not getting consistent results from i7 Turbo at full load then try turning off any additional monitoring programs that might be interfering with the Calculated Multiplier. Programs that sample a lot of motherboard voltages like HW Monitor and Everest have been known to cause problems on some motherboards when testing with i7 Turbo.

Edit #2: RealTemp 3.00 can also cause issues with i7 Turbo results when the internal timers overflow and wrap around back to zero. When you are testing, I recommend that you update to RealTemp 3.30 which handles timer wrap around better.

http://www.fileden.com/files/2008/3/...alTempBeta.zip

i7 Turbo displays both the calculated multiplier as well as the traditional MSR based multiplier. On a Core i7-920 at full load with the Turbo fully engaged, both of these values should be firmly locked on 21.000. At full load, if the calculated multiplier starts to drop, that is an excellent warning sign that Turbo throttling is starting to occur.

For the MSR based multi, I am sampling it once per thread per second to improve its accuracy. If you have hyper threading enabled and it samples 7 of your threads at a multiplier of 21.0 but the eighth thread has dropped down to 20.0 by the time it gets sampled, then it will display 20.875 showing that the Turbo was mostly enabled during that sample period. On Core i7, the multiplier is a whole number and at any instant in time it will be the same for each thread but with multiple samples during a one second interval, we should see better results from the MSR based multiplier.

For severe cases, both multipliers will drop down to 20.000 and clearly show Turbo throttling in progress. Other times, maybe the calculated multiplier will give you an earlier warning of this problem.

Both multipliers and the Average CPU Load can be logged for further analysis. The load of each thread is displayed in the GUI. While testing, you can easily add a note directly to your log file like, "Started Prime95" or "Started LinX." You can use either the Enter key or click on the Add Log Note feature.

The EIST section reads this information directly from the CPU. If it disagrees with what you set in the bios then that's usually a sign that your bios is not turning off this feature.

The Load Filter option for the Calculated Multiplier lets you weed out any bad data from the Min and Max areas that can occur with this method when the CPU is lightly loaded. If you set it to 0% then all calculated multiplier data will show up in the Min/Max area. If you use 90% then data will only be added to the Min/Max area if the CPU load is 90% or greater. I added this so if you're gaming, light load between rounds or when going back to the desktop won't interfere with your results.

Many thanks to rge for helping to thoroughly test this tool. His Gigabyte board used to have Turbo throttling issues too until the bios guys listened to the complaints and fixed this issue.

Update: 6/23/2009
-----------------------

Asus is working on some extreme bios versions for Xtreme users to finally disable TDP/TDC/Temperature based Turbo throttling for their P6T series. I'll post more info when it becomes available and hopefully some links where you can download special bios versions to disable Turbo throttling.

Edit: Early testing looks great. If you have an Asus P6T v1 then contact me for an updated bios. No more turbo throttling. Hopefully once Asus gets some feedback they will build a few more special bios versions for the rest of the P6T motherboards.

[dejanh]

Thanks! Good tool, highly recommended especially if testing. I used this way back when it was just one box showing the multiplier to diagnose the R2E. Managed to get Asus to add TDP limit enable/disable feature to the board BIOS soon after

[unclewebb]

Managed to get Asus to add TDP limit enable/disable feature to the board BIOS soon after

You're welcome. We're hoping this tool will encourage Asus to do the same for the P6T.

[Leeghoofd]

Thx man will add this to the test setup

[rge]

Worked great for testing GB boards as well and figuring out what was going on with turbo.

Here is early GB bios F3 with turbo limits engaged. As soon as cpu pulls roughly 107-110W (system pulling 389) turbo begins to throttle, see calculated and msr multis and min/max.




And here is what bios f4 betas to most recent bios 8b does on GB boards, with turbo TDP limit turned off...even if cpu pulling 224W (system pulling 590) turbo is still engaged. I purposely used 1.5Vcore and 4.3 ghz to show turbo stays engaged at high watts. But when cold outside, I can run 4.6ghz with 1.68 vcore and pull 300W per everest, and turbo still fully engaged.

[Movieman]

Now if you can come up with a way to make the settings adjustable on a Dual Nehalem board I'll hug ya!
Nothing works. SetFSB has the proper PLL controller in it but when you start it, it grays out and goes into a endless loop/ Need to do a CTRL/ALT/DEL to shut it off.
Ideas? Thoughts? Go away and don't both you?

[003]

Please sticky this thread.



Motherboard: Asus P6T Deluxe V1
BIOS: 1604
CPU Speed in BIOS: 191 * 21 @ 1.4125v w/ LLC

Notice how i7 Turbo is reporting a multiplier of 20.875 (1/8 threads running at 20x), but all other programs still report 21x.

If I increase bclock to 200MHz (and voltage to 1.49v), the multiplier drops entirely to 20x on all threads as soon as the full load of LinX is placed on the CPU.

[unclewebb]

003: Your screen shot is confirming the theories I have about Turbo throttling and how most software ignores this problem until after it has been happening for a while. Congratulations. Your Asus P6T Deluxe is going to be the first entry in the Wall of Shame that I'll be creating in the first post. If Asus ever gets around to releasing a bios to fix this then I will post that information as well.

Approximately 4 GHz and 1.40 core volts is where this problem first appears when running LinX. If you have the time do some more testing and post some more screen shots. Run some Prime95 as well for comparison. It draws less watts so you should be able to go a little higher before Turbo throttling starts. If you can, include the Everest Power Consumption numbers as well like rge did.

Any screen shots that show different levels of Turbo throttling along with how various programs report it would be great. RealTemp 3.20 is using this method to calculate the multiplier but because it rounds off its results to the nearest 0.5, it probably won't show 20.5 until the calculated multi is less than 20.75.

[nutcase]

ok, I will post mine. not as bad

full load using Boinc Manager and 2 different projects running

[unclewebb]

nutcase: Your calculated multiplier and MSR multiplier are the same 21.000 in your screen shot.
At 4200 MHz and only 1.304 volts, your Turbo is fully engaged in this screen shot.

[road-runner]

Not sure exactly how it works but here is the Classified...

[unclewebb]

road-runner: The calculated multiplier is not 100% accurate at idle so when running LinX, you might need to crank up the Load Filter in the top right corner to prevent low CPU load from screwing up your calculated multiplier Miin/Max results. LinX drops the load between each round.

In your screen shot, the real time calculated multiplier in the top left corner shows a steady 21.000 when your CPU is at 97+% load so no Turbo throttling is occurring.

Here is 003's example:



At 99.59% load, the calculated multiplier has dropped down below 21.000 to 20.875. That's usually the first sign of Turbo throttling. This example also shows that the calculated minimum multiplier is 16.370 which might be a sign that EIST is not fully engaged. In Windows Vista, if you want your multiplier to drop down to 12.000 at idle then you need to reduce your Minimum processor state to about 50%.

[anzial]

Did on my classified, 3 loops of lynx, the temp topped out, and the calculated multi was the same as MSR (21). However, min calc multi was something like 20.969 or something. Well, classified is supposed to be an overclockers board, no?

[The-Fox]

nutcase, you are right on the edge of exceeding TDP limit.
Try to raise the vcore to 1.35v-1.4v and you will see the multi starts to drop

[unclewebb]

The-Fox: CPU power consumption at full load is proportional to voltage squared so a 10% increase in core voltage will get you an approximately 21% increase in power consumption. A little extra voltage will definitely get you closer to the TDP throttling point faster. Does the Foxconn Bloodrage GTI allow you to turn off TDP based throttling in the bios? The X-Bit Labs review seemed to hint at this problem but they might not have had the bios set correctly or didn't understand the data they were seeing.

For those that spend most of their computer time gaming, Turbo throttling is not likely to be an issue. It's hard enough to find a game that is able to fully utilize 8 threads let alone put a load on those threads the way LinX does.

Here's the simple instructions:

If you have a 920 with Turbo enabled; at full load, if your Calculated Multiplier or your MSR Multiplier are dropping below 21.000 then that is a good sign of the Turbo starting to throttle back to a 20.0 multiplier. At higher MHz or higher core voltage, this problem will likely get worse. If you are testing with a program that has frequent drops in the Load like LinX does, try using a higher value in the Load Filter box to filter out any data from your Min/Max results that occurs when the CPU is lightly loaded. For LinX, maybe a Load Filter of 50% or higher is appropriate. When there's a problem, it's easy to use the log file to compare your multi to your load values. At 99% load, the Turbo should be fully engaged and both multipliers should be at a constant 21.000.

[The-Fox]

The Foxconn Bloodrage GTI (and non GTI Version) lets you bypass the TDP limit in the latest BIOS versions.
I have a compatibility Issue with the Perc 5/i card on the newer BIOS versions, so for now I am stuck with the G13 version which is very old and doesn't support overriding the TDP limit.
Here and then I flash to the new BIOS versions, perform some benches and then flash back to G13.
Hopefully Foxconn will have a solution for me, otherwise it will be a no go for this board.

[devsk]

You can add Asus P6T Deluxe V2 0504 to the wall of shame. This thing throttles like crazy. I have tried two chips: 920 and w3520. And both start to throttle at about the same CPU temperature. Confirmed with realtemp and hardware monitor, AND the turbo tool alone.

When hardware monitor reports CPU temp (tcase) greater than equal to 68C (tcasemax is 67.9C or something like that), multi falls to 20.5 in realtemp. I think the throttling is tied to tcase rather than TDP. The output power doesn't change with lowering my ambient temperature but CPUTIN does. And so does the throttling. I think we are way past the TDP limits (130W or even if 150W) at 4.2Ghz and 1.35v vcore anyway. And my D0 throttled at 1.225vcore doing 4.2Ghz. My w3520 throttles at 1.35vcore at 4.3Ghz. Same tcase temps in both situations.

[unclewebb]

You can add Asus P6T Deluxe V2 0504 to the wall of shame.

I'd be happy to. Your motherboard has been added. At least now when people contact Asus to fix this issue they can point them to this thread.

HWMonitor will interfere with the timers that RealTemp and i7 Turbo use to calculate the multiplier so I'd recommend not running that program or anything else while testing. I'm not sure of how other programs will effect your results. RealTemp and i7 Turbo get along fine together.

What are your core temps up to when TCase is reading 68C?

The more information that documents this problem that you can post here the better. I'm not sure if Turbo throttling based on TCase temps is motherboard or Intel related. Upload some screen shots at www.imageshack.us and post the links here.

Edit: Here's what the Intel Turbo White Paper says.

1.2 Dependencies / Algorithm
Intel® Turbo Boost technology core frequency upside availability is ultimately constrained by power delivery limits, but within those constraints, it is limited by the following factors:

• The estimated current consumption of the processor
• The estimated power consumption of the processor
• The temperature of the processor
------------------------------------------------------

So it looks like temperature does play a direct part in this. I've read elsewhere that a core temperature in the high 80C range can also trigger Turbo throttling.

[devsk]

I'd be happy to. Your motherboard has been added. At least now when people contact Asus to fix this issue they can point them to this thread.

Thanks!

HWMonitor will interfere with the timers that RealTemp and i7 Turbo use to calculate the multiplier so I'd recommend not running that program or anything else while testing. I'm not sure of how other programs will effect your results. RealTemp and i7 Turbo get along fine together.

I read your post and hence I never ran them together. I ran realtemp and hwmonitor and they seem to play nice (except may be once when hwmonitor decided to close on me).

What are your core temps up to when TCase is reading 68C?

Around 84-85C.

The more information that documents this problem that you can post here the better. I'm not sure if Turbo throttling based on TCase temps is motherboard or Intel related. Upload some screen shots at www.imageshack.us and post the links here.

I will do that once I repeat my experiments.

Edit: Here's what the Intel Turbo White Paper says.

1.2 Dependencies / Algorithm
Intel® Turbo Boost technology core frequency upside availability is ultimately constrained by power delivery limits, but within those constraints, it is limited by the following factors:

• The estimated current consumption of the processor
• The estimated power consumption of the processor
• The temperature of the processor
------------------------------------------------------

So it looks like temperature does play a direct part in this. I've read elsewhere that a core temperature in the high 80C range can also trigger Turbo throttling.

I have two D0 chips: w3520 and i7 920. 920 runs 4.2Ghz at 1.25vcore while the other one runs 4.2Ghz at 1.3V. 920 throttles at 4.2Ghz but w3520 doesn't because although 920 uses less volts, it generates more heat. I don't know why but D0 920 generates more heat at 1.2v than a C0 920 at 1.4v. This is the reason why I can run 21x201 with w3520 but can only use 19x221 with 920 because 19x221 requires less volts and is less hot and doesn't throttle.

I would assume power consumption is more for same clock if volts are more. So, power consumption looks secondary to throttling.

[devsk]

I just ran the program and prime. Set the filter at 80%. It reported one spurious looking 16.670 as minimum. Looking at the log file, mostly 21 but many 20.3/5/7/8 as well. So, throttling happened. Max core temp in realtemp was 87C. Don't know the tcase because hwmon wasn't running.

Why would we see a min multi of 16.670 when the cores were all loaded for all the time during 11 mins?

[unclewebb]

Why would we see a min multi of 16.670 when the cores were all loaded for all the time during 11 mins?

Good question. Were you running Small FFTs? That does the best job of maintaining a constant load. Next time you run a test turn on the logging feature so you can go back and see what the CPU load was when that number occurred.

The calculated multiplier is not 100% accurate, 100% of the time but at full load, it's usually very steady. I have a few ideas to improve its accuracy further but I don't know if I need to. At the moment, it seems more than accurate enough to show Turbo throttling in progress.

If you can, send me a log file of about a one hour Prime95 Small FFT run so I can go back and see and come up with a typical error rate.

Real_Temp@yahoo.ca

The error rate might be 1 in a 1000 or who knows. If the Calculated Multi is spitting out piles of errors at full load then I need to do what I can to improve it. If your system is not 100% stable at full load or bouncing off the TDP limit then that might also be a source of errors in the timers I'm using.

When testing, boot up with Turbo disabled in the bios so we'll be able to tell how consistent and accurate the calculated method is without Turbo throttling confusing the issue.

Edit: You're not the first person that has reported the issue of less core voltage not equaling less heat. I definitely don't have an answer for that one.

[anzial]

Hey, is it possible to show the multis on each core individually?

[drnip]

Wish it would help figure out the 12 mult DFI problem.

[unclewebb]

rge and I just finished a couple of 4 and 5 hour runs of Prime95 Small FFTs and the MSR Multiplier and the Calculated Multiplier were both locked on 9.000 for my Q6600 and his Core i7 was locked on 21.000. At full load, these timers look accurate and very consistent.



I had a look through my log file and there wasn't one time when it dipped below 9.000 until I stopped Prime95. I'll have a look through rge's Core i7 data later tonight.
Edit: rge's log file was as boring as my file. 4 hours 21 minutes of Prime95 at an average load of 99.91% and two columns of the number 21 and never did it dip below that.

You can download his log here:
http://www.fileden.com/files/2008/3/...i7TurboLog.zip

Hey, is it possible to show the multis on each core individually?

That's possible. You can report either the Calculated Multiplier or the MSR Multiplier for each thread on a Core i7 or each core for a Core 2 based CPU. On a Core i7, all multipliers should report the exact same thing. During Turbo throttling or during an EIST transition, it's possible that the first thread might be different than the last thread just because it's impossible to read all 8 threads at the exact same time. On a Core 2 Quad, it is possible for the 2 Core 2 Duos inside of it to operate at full load with two different multipliers but this only happens if you have a bios issue or you write some different values into MSR 0x199 which controls the multis.

Here's a Core 2 Quad example of a bios issue.
http://www.xtremesystems.org/forums/...postcount=3490

drnip: The DFI, Windows 7, 12 multi is an interesting issue. When I get the chance I'm going to have another look at this to see if I can come up with a light weight app to trick it to the higher value. Nag me every few days with a PM until I send something your way for testing.

[anzial]

I'm only asking so that to test the elusive +2 turbo Could you add that into the progam?