# i5-1035G4 on the Surface Pro 7 throttled by an odd hardware failure



## WaseemAlkurdi (Nov 7, 2022)

Hello!

*Long, winded rant ahead ... truly sorry, planned a short post, ended up ranting :-(
* TL;DR at the end **

Few letdowns in the tech world beat that of thinking that you've upgraded, only for that gradual realization that things have become slower, not faster, to sink in. You try to dismiss that as delusions, but the incessant alarm sirens just keep getting louder and louder; no, you've definitely gotten screwed, and things are undoubtedly, undeniably, visibly, obviously slow.

This is the exact headache I've been dealing with for the last few months now. I used to own an HP Elite x2 1012 G1 that I've asked you about earlier this year: since then, it has behaved itself, with your awesome advice! But pain of a poor battery, along with the ache to upgrade, the temptation of a faster tablet with more battery is hard to resist.

So, I caved in. I bought myself a secondhand Surface Pro 7, with a Core i5-1035G4, 8 GB of RAM, and a 128 GB NVMe SSD, in the hopes that it'll be both faster and more efficient than the venerable, but tired, Elite x2.

It was painfully obvious ever since booting it for the first time that something was wrong: every Windows animation is choppy!
At first, I put it down to Windows needing an OS reinstall, especially since it's arrived with a Windows copy preinstalled. So, I downloaded the Surface Recovery Image and reimaged it back to factory fresh.
No dice. It was still laggy.

At first, I reluctantly attributed that to the HiDPI "PixelSense" display of the Surface compared to the 1920x1200 of the HP Elite X2 - but that got quickly disproven when I set the Surface to a close resolution and the issue still persisted.

I then tried disabling the Intel Dynamic Tuning Service as suggested online, but to no avail.

Looking in Task Manager, I could notice two odd things:

with normal (web + office) usage, the CPU NEVER clocks above 1.50 GHz, preferring to stay around the base clock of 1.10 GHz. This is in stark contrast to the old HP, which freely boosts up to 2.50 GHz and beyond when interacting with it, then dropping back to 1.10 - 1.50 GHz when idle.
the only time the CPU clock speed goes above 1.50 GHz is when playing a video - and when it does that, the animations become noticeably more fluid.

Notably, both CPUs list "@ 1.10 GHz" in the CPUID string viewable in Task Manager, both share a base frequency of 1.50 GHz, also viewable in Task Manager, and both are fanless designs. Therefore, it's intuitive to assume that the fanless i5-1035G4 in here is an evolution of the Core m5-6Y54, an m5-1035G4 if you will.

Also, both laptops used up exactly 7% in exactly 15 minutes of benchmark testing - nor does it do any better in daily usage, with both getting at 4-5h of battery life, except that one battery is 6 years old, and the other is hardly two years old.

______________________________

With the above, I thought, "looks like a repeat of the HP Elite x2 then! I'll open up ThrottleStop, then undervolt it, problem solved!"

Alas. The fun-at-parties people at Microsoft decided to completely butcher the device by locking the 0xE2 MSR in order to patch Plundervolt ... on a CPU that was never vulnerable to begin with!

Sigh.

And it's just begging for an undervolt: the CPU measures around 0.74 volts, a full 0.20 volts higher than the m5-6Y54!


Tried looking into downgrading the UEFI by forcing a UEFI capsule update with an older UEFI capsule, but Microsoft has patched that hole by raising the minimum version that one could downgrade to, to a version newer than the prior publicly-available release. They effectively shut that loophole too. Attempting to edit the UEFI variables to disable CFG-Lock on a device that cannot be opened to reset the CMOS and is prone to bootloops is a tad risky, and that's assuming I could find the CFG-Lock variable in the stock Microsoft UEFI images to begin with - they might be using another method, possibly a "new" microcode revision.

Now I'm left with a device that won't undervolt and is being severely choked.

I took out the ThrottleStop benchmark for a spin side-by-side with the older device. I disabled the undervolt on both, set the Speed Shift EPP multiplier to the same value (tried with 84 and 128), disabled BD PROCHOT on the Surface, then ran the benchmark.

Initially, the Surface did a bit better, but then I noticed that the Surface had 8 cores at its disposal.

With 4 cores on both ... the Surface actually did WAY worse, taking 77 seconds to complete the benchmark vs. 58 for the m5-6Y54: something like 20 seconds slower! This didn't make any sense at all.

During the test, the CPU never boosted above 1.49 GHz, and C0% never raised above 52%. On the other tablet, both valued freely soared to $A_LOT GHz and 100% for C0%.

Throttle Reasons shows "EDP OTHER" in all three columns during the test. The other squares light up after doing other tasks, but TS Bench never gets anything to light up except "EDP OTHER".

Tried IGPU=30 to fix that last "EDP OTHER" throttle reason, no avail.

I'm at a loss here. Completely. And this time, hardware failure looks like even more of an ominous possibility, and where I live, there are no Microsoft repair centers, so if there was nothing else to do, I would have to live with this migraine of a tablet, a possibility I would do anything to avoid!

Thanks a lot!

______________________________

*TL;DR:

Fanless i5-1035G4 in a Surface Pro 7 is laggy in everything, gets throttled at 1.50 GHz except during video playback, scores 20 seconds less in matched-core-count TS Bench than a six-year-old m5-6Y54 - during which the CPU is locked to 1.49 GHz and C0% never climbs more than 52%, "EDP OTHER" lights up, decreasing screen resolution does nothing, disabling Intel Dynamic Tuning Service does nothing either, runs at ~ 0.75 V, no option to undervolt due to Plundervolt fix, no option to downgrade UEFI.*


----------



## unclewebb (Nov 7, 2022)

On the main screen set Speed Shift EPP to 84, not 128. Click on this value to edit it. 

Post a screenshot of the TPL window. There are things that are not locked that can be adjusted there that might help the cause.


----------



## WaseemAlkurdi (Nov 8, 2022)

Tried an EPP of 84 as in the screenshot below, same unfortunate result :-(
 Also attached is a screenshot of the TPL window as requested:


----------



## unclewebb (Nov 8, 2022)

Set Power Limit 4 to a value of 0 and check the MMIO Lock box.


----------



## WaseemAlkurdi (Nov 8, 2022)

unclewebb said:


> Set Power Limit 4 to a value of 0 and check the MMIO Lock box.


Tried it - no improvement :-(

(Attached are my TPL window and my benchmarks after locking the MMIO and setting PL4 to 0)


----------



## unclewebb (Nov 8, 2022)

Turn on the Log File option and attach a log file of your testing to your next post. The log will be in your ThrottleStop / Logs folder.

Open Limit Reasons while you are testing. Does anything light up red? Take a screenshot while the CPU is loaded.

Are you plugged in while testing or are you testing while on battery power? I avoid doing any full load stress testing while on battery power.

Try running a TS Bench - 1 Thread test. What speed does your CPU run at then? The G4 processor has a 15W TDP rating. Long term, it might be locked to that value.


----------



## WaseemAlkurdi (Nov 8, 2022)

unclewebb said:


> Turn on the Log File option and attach a log file of your testing to your next post. The log will be in your ThrottleStop / Logs folder.


Done - you can find them below!


unclewebb said:


> Open Limit Reasons while you are testing. Does anything light up red? Take a screenshot while the CPU is loaded.


The only light to light up during the benchmark runs is the "EDP OTHER" light for the Ring column.
However, the frequency of it lighting up depends on how many threads are in the test and whether it's connected to charger or to the battery. It lights up more while on the charger, especially when more cores are involved.

Apart from that, nothing else lights up during benchmarks.
The PL1 and PL2 lights do light up occasionally, but after letting TS run in the background and using the machine, but not during synthetic benchmarks.


unclewebb said:


> Are you plugged in while testing or are you testing while on battery power? I avoid doing any full load stress testing while on battery power.


I did all tests prior to this on battery. Plugging it in does allow the CPU frequency to raise above 1.5 GHz, but there is still slight jitter that perfectly coincides with "EDP OTHER" lighting up ...



unclewebb said:


> Try running a TS Bench - 1 Thread test. What speed does your CPU run at then? The G4 processor has a 15W TDP rating. Long term, it might be locked to that value.


Done!

Below you'll find all logs and screenshots of the all four benchmarks, labelled accordingly.


----------



## unclewebb (Nov 9, 2022)

Try checking the Speed Shift box in the TPL window. You are right that your CPU is getting stuck with the 15 multiplier when running on battery power when it really should not be doing this. 

Are you running any manufacturer's software to control the CPU? Some fan control software can screw around with the CPU.

When plugged in, your CPU is running correctly. During your 4 core test it is using the 33 multiplier which is what it is supposed to be using. During your 1 core test, ThrottleStop shows a peak multiplier of approximately 36.9. The maximum possible according to the turbo ratio limit values in the FIVR window is 37. It is impossible to ever see the full 37 multiplier during any single core test because there are always Windows background tasks that can wake up an additional core or cores. This momentarily reduces the multiplier from 37 to 36 or to 33 if multiple cores need to be activated. 

There are no problems when plugged in. Hopefully the Speed Shift adjustment can help out when running on battery power.


----------



## WaseemAlkurdi (Nov 9, 2022)

unclewebb said:


> Try checking the Speed Shift box in the TPL window.


This worked like a charm, thanks a million!!!!!! 


unclewebb said:


> Are you running any manufacturer's software to control the CPU? Some fan control software can screw around with the CPU.


I wish my tablet had any fans to begin with 


unclewebb said:


> When plugged in, your CPU is running correctly. During your 4 core test it is using the 33 multiplier which is what it is supposed to be using. During your 1 core test, ThrottleStop shows a peak multiplier of approximately 36.9. The maximum possible according to the turbo ratio limit values in the FIVR window is 37. It is impossible to ever see the full 37 multiplier during any single core test because there are always Windows background tasks that can wake up an additional core or cores. This momentarily reduces the multiplier from 37 to 36 or to 33 if multiple cores need to be activated.


Hmm, that explains it ...


unclewebb said:


> There are no problems when plugged in. Hopefully the Speed Shift adjustment can help out when running on battery power.


It did, and the difference in performance is palpable!

There is one minor itch though: the third "EDP Other" light (for the Ring column) lights up whenever anything even minimally CPU- or graphically-intense happens (such as opening the Start menu or any app with Windows 11 translucency effects)
It also happens when benchmarking. How do I diagnose that? I have a hunch that this EDP (Embedded DisplayPort aka iGPU?) throttling is what's accounting for the minor remainder of lag left, and even if it weren't, I would love to let the Surface "breathe" freely without any throttling ... 

(See pic below from a benchmark without vs. with Speed Shift for an example)

_______

Also, I've noticed that after a fresh restart (no charger), even when Speed Shift isn't enabled, the CPU would run fine for about 10 seconds before something or the other sets in and throttles it - I have seen the cutoff point and drop in performance with my two eyes during a benchmark started right at system boot. It's definitely not the Intel Dynamic Performance Tuning service since that phenomenon occurs even if said service is disabled, but what could it be other than that?


----------



## unclewebb (Nov 9, 2022)

WaseemAlkurdi said:


> thanks a million!!!!!!


You are welcome. I still get a big smile when I see a success story like this. 



WaseemAlkurdi said:


> the difference in performance is palpable!


The CPU being allowed to use the 37 multiplier when lightly loaded on battery power vs being held back to the 15 multiplier is an almost 150% increase in CPU speed. That is definitely going to be noticeable. 

The question now is, why is Microsoft doing this? Are they trying to protect the battery? Probably. Is using ThrottleStop to overcome this limitation dangerous? Maybe but probably not. If your Surface Pro has a battery fire then I guess there was a reason for Microsoft's decision to run your laptop in limp mode when on battery power. 

I think manufacturer's need to be more honest about these built in throttling features. If they mentioned on the sales sheet that your Surface Pro was going to limp along at 1500 MHz when on battery power, most users would walk away without buying it. Instead they pretend that your Surface Pro will be able to run at its full rated speed when on battery power which is impossible without the help of ThrottleStop.



WaseemAlkurdi said:


> EDP (Embedded DisplayPort)


EDP actually stands for Electrical Design Point. This is typically a current limit.



WaseemAlkurdi said:


> the third "EDP Other" light


It is usually the IccMax values in the FIVR window that control this. Unfortunately, Microsoft has set the Lock bit on CPU voltage control so there is no easy and safe way to unlock this feature. The low ball IccMax values that Microsoft are using, 70.00 Amps, are likely what is causing the cache (RING) EDP throttling that you are seeing. At least the core is not throttling when this happens. The core speed is more important than the cache speed. 

When you are running a benchmark and you see EDP glowing red, have a look in the FIVR monitoring table to see what speed the cache is actually running at. The 1035G4 has a very low base frequency of 1.10 GHz so the cache might be limited to an 11 ratio when the CPU is loaded and EDP throttling is in progress. 





The only possible fix is to unlock CPU voltage control so you can increase IccMax. Do some Google searching to find out if anyone with your Surface Pro has done this. It involves changing a couple of UEFI variables. Search for UEFI unlock voltage and start reading. The procedure is overly complicated and might damage your laptop. To get the cache running at full speed if possible, risking everything to do this might not be worth it. 



WaseemAlkurdi said:


> but what could it be other than that?


I am really not sure what causes the Speed Shift Max value to get changed. All I know is that ThrottleStop can be used to fix this problem / feature. 

When plugged in, have you tried checking the High Performance box on the main ThrottleStop screen? This tells Windows to switch to its hidden High Performance power plan. Try doing that and change the Speed Shift EPP value on the main screen from 84 to 0. This tells the CPU to run at full speed when lightly loaded. This feature might help reduce any slight lag that you are experiencing. If you do not notice any improvement, use ThrottleStop to go back to the default Windows Balanced power plan and then you can clear the ThrottleStop power plan box. 

Running a CPU at full speed when lightly loaded is not a horrible thing to do. Unused cores automatically enter the low power C7 state where they are disconnected from the internal clock and they are disconnected from the voltage rail. Technically unused cores are sitting at 0 MHz and 0 volts. In other words, using the High Performance power plan to run idle cores at 3500 MHz is a little deceiving. 99% of the time the idle cores are in C7 and not running at any speed let alone full speed.


----------



## WaseemAlkurdi (Nov 10, 2022)

unclewebb said:


> You are welcome. I still get a big smile when I see a success story like this.


Man, you're a legend! You've done so much good to the world with ThrottleStop, and I truly wish you all the best going forward!


unclewebb said:


> The question now is, why is Microsoft doing this? Are they trying to protect the battery? Probably.


Given their atrocious thermal design on the Surface Pro 4 and 5 where the (hot!) heatpipe is sandwiched between the battery (cue spicy pillow) and the display (leading to it failing when the hot battery swells and squeezes it), they might be trying to avoid this whole mess.

Except that this is clearly not the way! 
I'm sure that stacks of them had to be replaced by Microsoft at a loss to them - my classmate was one of these, she was fortunate enough to have bought hers new, and the warranty gave her a brand-new 7+ in exchange (she had to pay up $140 however)


unclewebb said:


> Is using ThrottleStop to overcome this limitation dangerous? Maybe but probably not. If your Surface Pro has a battery fire then I guess there was a reason for Microsoft's decision to run your laptop in limp mode when on battery power.


Fortunately mine rarely if ever overheated - it did overheat in the lower-right corner once (before TS, while throttled), but shutting it down and waiting resolved it, and it hasn't ever overheated since.


unclewebb said:


> I think manufacturer's need to be more honest about these built in throttling features. If they mentioned on the sales sheet that your Surface Pro was going to limp along at 1500 MHz when on battery power, most users would walk away without buying it. Instead they pretend that your Surface Pro will be able to run at its full rated speed when on battery power which is impossible without the help of ThrottleStop.


This, and all this!
Or better yet, learn from Apple (back when Intel Macs ran cool, so before the USB-C era) and do a factory overclock ...
Or at least simply not lock the required MSR to begin with, on hardware that isn't affected by Plundervolt!


unclewebb said:


> EDP actually stands for Electrical Design Point. This is typically a current limit.


Ah. Good to know!


unclewebb said:


> It is usually the IccMax values in the FIVR window that control this. Unfortunately, Microsoft has set the Lock bit on CPU voltage control so there is no easy and safe way to unlock this feature. The low ball IccMax values that Microsoft are using, 70.00 Amps, are likely what is causing the cache (RING) EDP throttling that you are seeing. At least the core is not throttling when this happens. The core speed is more important than the cache speed.


Admittedly, the device also hits PL1 and PL2, but that happens so rarely that it frankly doesn't even matter.
I'm eyeing those voltages though, and that CPU running at ~ 0.75 - 1 V is plain saddening - it absolutely could take a -70 to -100 mV undervolt!


unclewebb said:


> When you are running a benchmark and you see EDP glowing red, have a look in the FIVR monitoring table to see what speed the cache is actually running at. The 1035G4 has a very low base frequency of 1.10 GHz so the cache might be limited to an 11 ratio when the CPU is loaded and EDP throttling is in progress.
> 
> View attachment 269276


During benchmarks, Cache Ratio boosts up to about 30 and the EDP Other light turns red until the load is lifted.
I wouldn't mind this much, but the Windows UI translucency also hits the CPU cache hard unfortunately, which results in minor stuttering (albeit much less than before.)


unclewebb said:


> The only possible fix is to unlock CPU voltage control so you can increase IccMax. Do some Google searching to find out if anyone with your Surface Pro has done this. It involves changing a couple of UEFI variables. Search for UEFI unlock voltage and start reading. The procedure is overly complicated and might damage your laptop. To get the cache running at full speed if possible, risking everything to do this might not be worth it.


People used to be able to downgrade the UEFI to a version that supported undervolting - but Microsoft blocked that.
Furthermore, combing through the UEFI update image with UEFITool doesn't reveal the existence of a variable controlling CFG Lock / MSR Lock / Overclocking Lock, so my guess is that either this needs a full UEFI dump or that CFG Lock isn't how Microsoft is locking out voltage control (or that there isn't a variable to toggle that.)


unclewebb said:


> When plugged in, have you tried checking the High Performance box on the main ThrottleStop screen? This tells Windows to switch to its hidden High Performance power plan. Try doing that and change the Speed Shift EPP value on the main screen from 84 to 0. This tells the CPU to run at full speed when lightly loaded. This feature might help reduce any slight lag that you are experiencing. If you do not notice any improvement, use ThrottleStop to go back to the default Windows Balanced power plan and then you can clear the ThrottleStop power plan box.


It didn't help with the stutter (it's certainly the cache throttle issue, given the perfect synchronicity between the cache throttle and the animation stutter) - but on the other hand, it gave me a nice 10-point boost on TS Bench, so I'm hanging on to it regardless!

About the cache throttle - I guess I'll either have mine disassembled and the EEPROM read, or, failing that, buying a busted but identical one and seeing what could be done. 


unclewebb said:


> Running a CPU at full speed when lightly loaded is not a horrible thing to do. Unused cores automatically enter the low power C7 state where they are disconnected from the internal clock and they are disconnected from the voltage rail. Technically unused cores are sitting at 0 MHz and 0 volts. In other words, using the High Performance power plan to run idle cores at 3500 MHz is a little deceiving. 99% of the time the idle cores are in C7 and not running at any speed let alone full speed.


Got it!


----------

