OP’s 95C is normal given the default fan curves and recommended power management.
i use default fan curves…
It is thermal throttling, I tried to force cool down the laptop to somewhere < 50C, suddenly the frequency boosted to 3.xGHz and temperature going up to ~90C
there might be some other threshold or trigger condition. I tried boosting the fan to 100% 7000rpm using ectool, and messed with other warning thresholds, the temperature is still regulated to ~60C, with slightly higher frequency.
Yeah, the default fan curve is really really flat, not even reaching 5000rpm when thermal throttling kicks in. I always use ectool to lower the fan_max temperature to around 75C. And a turboed 7840U in full load generates lots of heat, easily saturates the tiny heatsink.
Which power management are you using? TLP or power-profiles-daemon?
hmm, none of above. I use a small script to read temperature and manipulate
/sys/devices/system/cpu/cpu*/cpufreq/scaling_max_freq,
to keep cpu below 80C. but when the thermal throttle happens, scaling_max_freq are set to maxim 5132MHz.
kernel command line has
amd_pstate=guided
uhhh
wow… on my 7640u the fan curve is pretty aggressive, with temps never exceeding 80c
I think that I am observing something very similar, although I’m not quite sure what sort of limit I’m hitting (power, thermal, what else?) since I haven’t yet tried experimenting with external cooling methods. My system has a 7840u and is running NixOS 24.11. It was plugged in with the original Framework 60W power supply while conducting the tests below.
I have noticed when parallelizing a program of mine (solution to Advent of Code 2024 Day #6, bruteforce edition 
) that splitting the workload concurrently on all 16 threads only resulted in a 2x speedup. I have checked and running the single-threaded version results in the usual boost above 4.1 GHz, but running the multi-threaded version only gets to around 1.2 GHz.
Finding this quite strange, I have kept investigating and done several experiments using different workloads.
-
First I tried this browser based (https://mprep.info/gpu/) CPU stress test.
To my surprise, all cores jumped up to full speed and kept going for more than five minutes, after which I stopped the test. I kept monitoring the frequencies and temperatures withs-tuias well ashtop:
-
After that I ran some tests using
stressand found that once I get to about 10 to 12 threads, the drop in boost speeds sets in.
-
If I recall correctly, at one point I even had 10 threads, that started going strong, like shown below, but dropped off after a while:
Splitting the workload of my own initial program also coincides with this behavior, when I limit the number of threads to 9, I am able to get the full boost.
I am curious to know if these findings can be replicated by others, as well as potential steps that can be taken to get the maximal performance in all cases.
1 Like
In general using amd_pstate=guided is off the beating path where changing your frequency and the hardware tries to keep it. This generally does a better job than amd_pstate=passive, but why not use active mode and set the EPP? The hardware knows more about thermal capacity, utilization and other factors that the OS doesn’t so it generally does better than guided does.
1 Like
Something else really important I want to mention - there is a problem with the scheduler behavior right now.
There is a patch series in flight right now that helps it:
[PATCH 0/8] x86, sched: Dynamic ITMT core ranking support and some yak shaving
yeah 
, I definitely want to try some other pstate modes, but the AMD documentation is totally crap, only method might be Monte Carlo.
I am using a 140W DC PD adapter. FW13 can use 20V 4.5A, with some ectool configuration, I set it to 4.9A, when battery is charging it can draw more than 60W, up to 4.2A or so. 60W PD also limited to 2.7A, thus 54W.
And even worse, when I use gnu parallel with imagick to encode avif, some images running only 1 thread, so the system is running only 4 threads at painfully slow 1.5GHz
Wait what? You can use ectool to increase the input power?
yes, but I guess within PD reported capabilities.
% ${ectool} chargestate show
...
chg_input_current = 4900mA
...
code:
% ${ectool} chargestate param 2 4900
variable ectool is sudo and path of ectool
hmm, active looks much better. I’ll keep watching it.
I found that it’s reasonable for Framework to not to use full power. Here are two 65W power supplies, one can deliver 3.25A the other has trouble at 3A
1 Like
which one, may I ask?
This might also have to do with the un-grounded connection – 2-prong chargers technically have a floating voltage, since the charger don’t have a 0V (ground) reference. which can cause erractic readings if you are comparing it to gorund