fix Edit

setting MSR 0x1FC bit 0 to off (0) disables asus' method of throttling. it persists until you reboot.

  • grab the MSR tool at the bottom of the page
  • in MSR Number, type in 0x1FC
  • in the box under -0003 (EAX), type in 2 and Write MSR
  • Read MSR to make sure all cores are set to 0x02 and enjoy


  • use unclewebb's 1FC toggle in the tools section at the bottom.

OR (linux)

sudo apt-get install msrtool
sudo modprobe msr
sudo wrmsr 0x1FC 2

IMPORTANT: your temperatures will increase drastically during scenes where the throttling would normally occur. if the source is true, then this will also mean no more thermal throttling -> you will have to assume control and watch them like a hawk (at least the first time).

instances and description Edit

affects both the G51J and G51Jx.

once a hard-coded power draw trip point has been reached, the CPU will clock down to 7x. here is what we know about current values on a G51J (note that values less than 1W are an estimation, but the G51Jx will be very similar):
- the CPU uses 43-55W DC (prime95)
- the GPU uses 58W DC (furmark. the gts360m at stock is 50W)
- the idle total system power draw is 28-38W with the values below (acpi, linux)

bennyg1 adds: By using a Wall-socket power meter with battery removed - with 0x1FC in place, power draw NEVER exceeded 120W (avg over 3 sec) from the wall. With 0x1FC toggled disabled (through the util) I was able to exceed 120W draw and as high as 180W (CPU OC + GPU OC, prime95+furmark). IMO this is pretty clear evidence what trips the throttling, how it is achieved and why it is in place. It's sounds like the algorithm is part of the laptop's power circuitry - probably why ryzeki's experiement with a 150W adapter all those months ago made no difference. Bennyg1 03:43, May 12, 2011 (UTC)

using these values we can make a guess that asus has set the max draw at 90-100W before the CPU is cut. so far we have determined the cut is not initiated by PowerManagement or ACPI; disabling them has no effect. because it can draw more than the trip point, it is not a hardware limit either. see the BIOS disassembly page for technical details.

as of writing, there are few games and applications that require such a balance of CPU and GPU power including Dragon Age Origins, BF:BC2, Mass Effect 2, Dolphin-emu and pcsx2. when the trend does move to more multithreaded games, this machine will be outdated because the multithreading will end in throttling.

real-world theoretical and practical scenarios in which throttling will occur:

  • 1 core maxed @ 100% GPU usage.
  • 2 cores maxed @ 70% GPU usage.
  • 3 cores maxed @ --% GPU usage.
  • 4 cores maxed @ --% GPU usage.

3dmark06 test Edit

what to do

1 - run 3dmark06 on max brightness, record all three separate scores.
2 - overclock the GPU in 25MHz increments (recording every run) until the score drops. if you hit unreasonable temps or card instability before the score drops, do 2a. else, skip to 3.
2a - keep adding peripherals (burning a DVD, copying over eSATA, USB phone charger etc.) until you notice a drop in scores relative to the last.
3 - as soon as the score drops, take note of which (SM2 or SM3). with gpuz + tmonitor or throttlestop open and logging, check to see if the CPU drops to 7x in those tests, as well as GPU usage staying above 90%. some common times are listed under the symptoms.
4 - without changing the setup, rerun 3dmark at 10, 5 and 0 brightness. you should notice an improvement in the score and a reduction in throttling.

what is expected

-- fully updated windows xp sp3, using 195.55 drivers. no additional bloatware, no service and performance tweaking. below tests are while burning a dvd.
(stock refers to asus stock, 500/800/1250. 260 refers to 550/950/1375)

stock clocks, full brightness: [1] [10575 3dmarks, 4047 4826 3347 single]. slowdowns observed in SM2 tests @ proxycon when the barrel falls and firefly during both log scenes.
stock clocks, lowest brightness: [2] [10946 3dmarks, 4650 4530 3470 single]. no slowdowns observed.
stock clocks, screen off: [3] [10970 3dmarks, 4696 4533 3434 single]. no observations.
260 clocks, highest brightness: [4] [10679 3dmarks, 4156 4755 3461 single]. massive slowdowns observed in SM2 and a bit in SM3 tests.
260 clocks, 10 brightness: [5] [11179 3dmarks, 4391 5053 3438 single]. some slowdowns, SM2 only.
260 clocks, 5 brightness: [6] [11539 3dmarks, 4701 5099 3473 single]. minor slowdowns in SM2.
260 clocks, lowest brightness: [7] [11608 3dmarks, 4788 5093 3462 single]. no or unrecognizable slowdowns observed.
260 clocks, screen off: [8] [11899 3dmarks, 5052 5119 3491 single]. no observations.

-- fully updated win7, 195.55. no tweaks. something's underperforming, either the drivers or win7 altogether (but correlation is there and that's what counts)

260 clocks +20core, max brightness: [9] [9473 3dmarks, 3694 4130 3218 single] massive SM2 slowdowns. SM3 is terribad, still one or two drops in test2.
260 clocks +20core, 10 brightness: [10] [9883 3dmarks, 4007 4216 3245 single] still massive slowdowns, albeit less. SM3 clean.
260 clocks +20core, 5 brightness: [11] [10088 3dmarks, 4240 4215 3210 single] still slowdowns in SM2.
260 clocks +20core, screen off: [12] [10276 3dmarks, 4408 4215 3250 single] no observations.

how you know if this test shows the symptoms it's supposed to

running 600/1000/1450 clocks i have recorded these as the most common times with stuttering/slowdowns (lasting usually an instant to several seconds long):
SM2, test 1: 0:24, 0:31, 0:57, 1:14, 1:25
SM2, test 2: 0:02, 0:15, 0:43, 0:53, 1:00
SM3, test 1: 0:20, 0:34, 0:48, 0:53, 1:02
SM3, test 2: 0:22, 0:32, 0:46, 0:54, 1:05

with RealTemp running on an external monitor or TV, the CPU will dip into 900MHz when it should be at 2.6/8 turbo boost the entire time.

with gpu-z, the GPU usage will take a dip <50%. see [13], [14], and [15]. <- these are screenshots for SM2 test2.

furmark testEdit

what to do

while furmark is rendering (stability, 4xaa, xtreme burn, windowed 1440x900), have tmonitor open. while adjusting brightness, observe the CPU speed

what is expected

same system as the previous test. furmark ready, not rendering, stock clocks: [16]
furmark active, rendering: [17] -> fan spins up, CPU clock goes down
furmark active, rendering, fan at less than full: [18] -> alternating between lowest and highest brightness and it's effect on CPU clocks
if you're lucky and the video driver isn't performing too well, test 3 will induce it.

how you know if the test shows the symptoms

while furmark is rendering, one core should be at 2.6/8GHz the entire time _without_ drops. if it's not, this is because the CPU is not getting enough power

furmark + prime95 testEdit

what to do

start crunching small or large FFTs in prime95. tmonitor should show all 4 cores at 1.6GHz (1.7 with turbo).
now start up furmark with the same settings as test #2. start rendering. look at what happens on tmonitor.
toggle rendering with the space key and observe the effect.
wprime will work as well.

what is expected

as soon as furmark starts rendering, all four CPU core flatline

how you know if the test shows the symptoms

all cores throttled.

results and observationsEdit

ALLurGroceries' test run: I have finished testing thalanix theory, and I got these results on W7. Turbo Extreme, nothing open except RealTemp. NVIDIA 195.62. BIOS 204. I rebooted after each run. Important notes: One HDD is replaced with an Intel X25-M (not my W7 drive, SSD is for Linux only), and my lights are disconnected. This probably saves 1-3W compared to stock.

Backlight off: ORB results

3DMark Score      10168 3DMarks
SM 2.0 Score     4391
SM 3.0 Score     4044
CPU Score     3383

Brightness at 50%: ORB results

3DMark Score      10159 3DMarks
SM 2.0 Score     4394
SM 3.0 Score     4046
CPU Score     3358

Max brightness: ORB results

3DMark Score      10146 3DMarks
SM 2.0 Score     4390
SM 3.0 Score     4029
CPU Score     3373

Youtube vid of CPU throttling in Furmark while adjusting brightness with watt meter readout.
Youtube vid of CPU throttling in Linux

bennyg added 1st Feb 2010:

bennyg's results with 3dmark06:

No clear difference observed identifiable through either raw 3dmark06 scores, or by analysing GPU-z logs. No CPU throttling visible on Rivatuner log of CPU frequency during any 3dm06 run.

  • GPU-z logs did show periods of GPU utilisation below 95% for periods as long as 10 seconds, however these were roughly identical on all runs at the same speeds. [In separate observations, these periods of underutilisation did exhibit a clear trend, that with increasing clock/shader/memory speed, these periods were longer in duration with lower utilisation % figures. The majority occurred in the SM2 test FFF. That LCD brightness had no impact on these indicates the GPU is being held idle by some other means, e.g. waiting for CPU or GPU FSB etc.]
  • The only visible exhibition of stuttering/frameskipping etc. was in the SM3 test CF where the dragon bursts out of the water both times, and only for one or two frames over a fraction of a second. In every run regardless of speeds or LCD brightness.
  • Config: Win7 HP64, factory win7 install with a few uninstalls/updates, FW 195.62, Gentech BIOS 207.t10. GPUz, Rivatuner logs open in background. Default 3dmark06 settings.
  • [added 10-Feb-2010] Primary (OS install) harddrive replaced with X25M-G2 80Gb. All programs installed and run from this SSD. [end add]
  • All runs with identical settings bar brightness, Power4Gear profile "High Performance" [100% CPU with "Extreme Turbo"], GPU @ 590MHz core / 1500MHz shader / 1050MHz memory:

Minimum brightness, no keyboard lights: (3dm06 scores in sequence CPU SM2 SM3)

11690 (3403 5096 4917), 11712 (3436 5100 4912), 11689 (3387 5105 4919)

Maximum brightness, full keyboard:

11684 (3377 5111 4916), 11677 (3381 5101 4915)

FYI stock clocks no CPU overclocking my G51J scores about 10,050 3dm06.


bennyg's results with Furmark and Prime95:

  • Config as above (win7 hp64, factory install 2/ uninstalls/updates, fw 195.62, GPU @ stock 500/1250/800 speeds, bios 207.t10, LCD brightness 5/15)
  • Running a test with Extreme Turbo on quickly showed it became evident the only difference I could observe was that (subjectively) throttling occurred more often and for longer periods than without CPU overclocking, however the difference was not great.
  • A very brief test showed LCD brightness also to have an impact, whereby full LCD brightness caused less & shorter un-throttling than minimum brightness.
  • All furmark tests were windowed at 1440x900. Noted that by default, Furmark (as etqw.exe) is set in Task Manager to run only on Core 0. GPUz logs showed without exception GPU utilisation between 85 and 90% during all test phases with maximum GPU temps reached at 94-95C.
  • GPUz showed GPU speeds remained at stock speeds without exception.
  • Furmark only showed CPU 0 running at 2.5/2.6GHz (2.7-2.8 with Extreme Turbo). No throttling observed.
  • It seems whatever it is that determines throttling is being checked every 3.5 to 4 seconds, there was a very clear pattern when running these tests that when CPU speed would rise (from a throttled state) it would do so at regular intervals. If CPU speed fell back down during that period (e.g. on the 2, 3 and 4-thread Prime95 tests) it would not rise again until the next 'check' i.e. in one of these "~4-second cycles" the CPU could rise but dip back almost immediately, and would not rise again until the next "cycle" started, at which point it might stay up during the whole "cycle".
  • At all times, engaging a core with a Prime95 smallFFTs thread (by controlling the affinity of Prime95 through Task Manager) led to Rivatuner showing 100% CPU utilisation for that core. Not engaging a core with any Furmark or Prime95 workload showed the core clocked at 933MHz, with only on rare occasion thread utilisation spiking above 10% (monitoring and background processes)
  • "Sharing" a core/thread (thread 0) between Prime95 and Furmark exhibited no impact on Furmark rendering, ie. maximum temps reached remained the same.
  • My Throttling observations are hugely subjective. Sometimes on a given test phase no throttling would be visible for 20 seconds. Then it would start and not stop for 20 seconds. I have tried my best to give a rough estimate, perhaps more relative than absolute but the trend was clear to me.
  • Throttling seemed to occur much more frequently a couple of minutes into a test phase, when the GPU heated up to its max (94-95C).

CPU Throttling - visible by both Tmonitor64 showing all 4 cores flatlining at x7 multiplier [~933MHz, ~980MHz in Extreme Turbo mode] even when under load - was observed in the following circumstances:

- Prime95 8 thread (affinity 01234567) + Furmark = throttle as soon as both run simultaneously. Throttled 100% of the time. Very, very occasionally, a one-bar spike in Tmonitor could be observed, but other than that, total flatline @ 933 MHz.

- Prime95 4 thread (affinity 0246) + Furmark = throttle as soon as both run simultaneously. However for fractions of a second at a time, CPU speed would raise back to 1733MHz on all cores. Longest I observed I estimate at 1/2 second. Vast majority of time however throttled @ 933MHz.

- Prime95 3 thread (affinity 024) + Furmark = throttling observed. However occasionally, CPU speed on cores 0, 1 and 2 would be restored to 1733MHz, for periods mostly shorter than a second. Core 3 (unutilised) remained at 933MHz throughout. When the GPU was warming up (i.e. <90C) there was markedly less throttling.

- Prime95 2 thread (affinity 02) + Furmark = throttling observed. CPU speed would be restored to 2.2-2.3GHz for short periods, sometimes as long as a few seconds, but the majority of the time remained at 933MHz. A screen-wide Tmonitor graph would clearly show 2 or 3 periods of up and down-speed events across the 10 or so seconds that fit on the screen at a time. I would estimate 60-70% of the time the CPU speed was throttled. Very rarely throttled at all when GPU <90C.

Prime95 1 thread (affinity 0) + Furmark = very minor throttling observed when GPU ~94C, however most of the time (90%) the CPU speed was 2.5-2.6GHz on Core 0.

Prime95 1 thread (affinity 1) + Furmark [affinity 0] = no discernible difference from the 1 thread test immediately above.

In a separate test, I tried underclocking the GPU while Furmark + 2 thread Prime95 was running. Throttling occurrence reduced with decreasing clocks, and ceased completely occurring when GPU was downclocked to approx 300MHz core 600MHz shader 300MHz memory. i.e. Furmark with GPU @ 300/600/300 + Prime95 2-thread affinity 02 showed CPUs 0 and 1 constantly at 2.2-2.3GHz in Tmonitor.

  • CONCLUSION: I subjectively observed a clear trend - the more cores actively crunching Prime95 threads, the greater the extent of throttling. If Tmonitor had a log feature whereby data could be stored and analysed I am confident this trend would be borne out by statistical analysis of that data. The Realtemp-associated program i7turbo shows it is clearly the multiplier that is affected when throttling occurs and the multiplier is set to the same minimum multiplier observed at complete idle state, x7 (133MHz base clock x 7 multiplier = 933MHz CPU speed).

1. The G51J-A1 does not have the capability within its power distribution curcuitry to run simultaneous stress tests utilising near-100% of GPU and CPU. Whatever monitoring that is built into the mainboard or CPU does so every 3 to 4 seconds and downclocks the CPU until the next iteration of the 'power check'. Whole system power consumption seems to be the issue as decreasing power draw from GPU (whether by lower clocks or lower temperatures) and even LCD appear to reduce the severity of CPU throttling.

2. This downclocking may be an error in BIOS (as in the now infamous Dell "throttlegate") or it may be a preemptive measure to ensure a stable power supply to components. Whatever the reason for it, I have observed no stability issues with either CPU or GPU (crashes, BSODs, Prime95 errors) during testing and indeed the only reproducible issue I've found so far is only by overclocking the GPU core beyond 590MHz (display driver crash & recovery) or memory beyond 1080MHz (3dmark06 terminate).

3. In my limited testing it seems the GPU has priority over the CPU, that is, throttling occurs on the CPU. In my experience so far, without exception.

4. Of course this purely synthetic scenario stresses the CPU more than any known or theorised game or game-style processing patterns do or will, and Furmark has shown me temps 1-2 degrees C higher than I've observed during any game as yet, but the possibility is there that at a future point a program will have the combination of CPU and GPU usage that will result in the G51J-A1's i7-mobile CPU throttling to 933MHz.

tools Edit

windows prime95

linux (must be run as root/sudo) (example: ./phoronix-test-suite run unigine-sanctuary )

links Edit

AW M15x Throttling Issue Investigation - Stock clocks and overclocked.
S-XPS 1645 AC Power Throttle Issue Investigation
S-XPS 1645 Throttling Info. and Updates
The Definitive Guide to Acer Aspire Gemstone Blue Throttling Issues v2.0
The Acer ThrottleStop Thread
Intel Turbo Boost whitepaper (PDF)