It would appear that you’re right, it’s just a slower version of that sensor.
It is the RAM sticks, but it’s not the RAM sensor it turns out but the actual RAM memory chips themselves. That explains why everyone seems to find something happening around the same temperature for the sensor, but nothing directly tied to it: it’s not the sensor actually doing the throttling.
I started with your PTM shim sandwich guide (and discovered a lot of the liquid metal had been wicked under the soldered shim somehow) to confirm I was not running out of general thermal headroom in the cooling system. After that modification I couldn’t overrun the cooling system with 100% CPU usage even with multi-hour test–I highly suggest it for anyone who wants the advertised performance of the FW16.
However I was still getting performance throttling with anything making heavy use of the RAM, and stumbled upon the thread linked above (shout-out to Alex_Morozov, excellent work!) which pretty dramatically documented this issue. I tested on my own machine by adding some thermal transfer pads directly on the RAM (both top and bottom) and have been unable to induce the thermal throttling ever since in any workload that previously would trigger it. I’m not sure if it’s truly fixed for any conceivable workload, since Alex continued to have some throttling, but I used Arctic TP-3 which has a bump over most other pads for thermal conductance so it might just come down to either hitting some minimum W/mK or using something soft enough to maximize the surface area contact.
The “F75303_DDR” despite coincidentally has a “DDR” in it, doesn’t mean it’s the RAM sensor. The RAM temperature sensors are “Spd5118,0” and “Spd5118,1”
Thankfully, I’m also not encountering any thermal throttling issues anymore. Under heavy load my device seems to happily sit between high 60’s and mid 70’s. Because I just love tinkering with it though, I’d be interested in cooling the ram anyways. Mind sharing what product you used to do this?
No it can’t be that because it is triggered when power states change, not ram usage.
@Charlie_6 Yep, but it turns out the actual sensor is irrelevant because it can show any arbitrary temperature without triggering the throttling.
So good for other people to know that the SPD sensors are the RAM thermal sensors, but more important for them to know that it doesn’t actually activate thermal throttling–at least in most cases since ambient temps high enough to trigger the SPD sensors would have long since triggered the memory chip throttling.
I think the additional holes you put in your case added enough airflow, and since you use a dGPU the load on the RAM should be less dramatic since it isn’t pulling double duty as VRAM.
I used Arctic TP-3 120x20mm 1mm thick and cut in half to give me two 60x20x1mm pads on both sides. It is extremely soft stuff, so even though the latches required some persuasion to close, it wasn’t enough that I think it will break anything–at least on my machine, but your part tolerances may vary. So if I was making a guide I would say use 0.5mm for the bottom (if you have double sided chips like the 48gb DIMMs) and 1mm for the top.
I might try it for the buck-boost chip and VRM as well if you find out the locations.
@jared_kidd
Read the thread I linked earlier, it’s pretty clearly the RAM for at least some throttling cases.
There seem to be ~4 different throttling causes (not counting the 545Mhz issue as throttling since that’s an unrecoverable state that won’t fix itself if you just let it cool down):
- Liquid Metal loss for primary CPU heatsink.
Some people have suggested that it thermally cycled itself out of position into the encapsulating foam, but for me at least it looks more like it dissolved or channeled through some of the shim solder. Adding more probably would have worked but I do worry long term if it would have dislodged the shim entirely.
The fix for this is using PTM, so later batches already have this. Replacing the shim for a PTM sandwich seems the best solution but requires some delicate work.
- Bad power EC firmware
This is the one that I think you’re talking about, there are two separate issues in one:
A. Chargers are limited to only ~80-90% of their advertised draw (and it doesn’t seem to correctly recognize when using a 240W charger and will treat it as a 180W charger) which means the overall power budget is more limited than expected.
B. The battery is supposed to be used for transient power spikes in excess of what the charger is capable of providing, but due to strange/bad logic it keeps flipping back and forth between charging the battery and using the battery.
- RAM throttling
This is what I had in particular, it’s not as relevant for people with DGPUs and may not affect every person depending on their RAM vendor. The 48GB Crucial DIMMs absolutely have a problem with this and I would suspect this holds true for all double sided DIMMs. The single side Crucial versions also seem to have issues, but they’re not as bad; so people may be able to get away with it depending on fan speed and usage.
To be frank, Framework needs to either formalize the pads as a part number or make some kind of note about high density DIMMs.
3.5. Fans don’t reach top speeds under normal fan controls
Not sure why, but Framework Control Center fixed it with the custom curve feature.
- I forgot
, I saw something else a few weeks ago on here that was a new one to me, I think it was also an EC related one, but it wasn’t the battery flipping or charger one that I know of. If I find it again I’ll link it.
When I was digging deep into these issues to troubleshoot my own laptop, I came across something else that you might find helpful. The AMD chips used ship with a feature called STAPM, which stands for Skin Temperature Aware Power Management. Essentially, it’ll throttle the CPU and GPU power if it determines that it’s proprietary algorithm, based on power draws and temperature readings, determines that the laptop is too hot. I saw this as the cause of some of (but not all) of my throttling events, so I went into the BIOS and disabled this feature and my performance became much more reliable (and the laptop skin temp feels no hotter). I may have needed smokeless umaf to do that, I don’t recall.
I recorded my exploits here (search for STAPM to jump to relevant section): [SOLVED] An Adventure In Mitigating Throttling
You can also just turn up the stapm temp at runtime using ryzenadj, no need for smokeless (also intitially did that to get around stapm throttling on the 13)
That’s a good tip!
Not mine I am just relaying it, at least on the 13 stapm is actually somewhat of a good thing to have as it does actually impact skin temperature but being able to dynamically set it to “desk mode” and “lap mode” is pretty neat.
On FL13, tuned-ppd and tlp-pd also do that, probably through PLATFORM_PROFILE_ON_AC/BAT. It lowers the STAPM wattage and threshold temperature when in power saver mode. For example in balanced/performace mode the FPPT/SPPT/STAPM are set to 53/35/30(performance) 51/33/28(balanced). The STAPM is like “PL3” in addition to traditional PL1 and PL2 in terms of TDP. In balanced mode it’s going to take a while to decrease from 33 to 28W but in power saver mode the power decreases from 25(SPPT) to 15(STAPM) very quickly. so the skin temperature is lowered as well. In this way, the power saver mode does enable “lap mode”
Unfortunately the bottom chassis is still hot to touch
