Extremely weird dGPU power behaviour on 140W chargers (moved)

Community Support
1

Hello to y’all - as a proud new FW16 Owner i got to play around with it over the previous days and thoroughly enjoyed this absolute beast of a Laptop so far on Fedora 40. However, i’ve ran into the most curious issues with it when i play games on it while using a temporary (until 240W USB-C chargers come out) 140W UGREEN Nexode Charger.

When i run games on the battery or a 60W anker charger everything works fine, both on the dgpu and igpu, with the expected performance reduction that i can live with - but of course that would also significantly cut into the time i could do so for, so i tried to run it on the 140W charger and it goes from mostly smooth vrr frametimes like that:

(Ignore the “Thermal Throttling” Line, its flatpak steam)

framework_60W
Sorry, only one picture, i can only post two images as a new user but imagine there being basically the same picture here for battery exclusive use saying “53 FPS” instead.

to this absolute mess:
Framework_140W

And its not just when trying to charge the battery, this also happens when full (60% set limit, and it still randomly drains the battery even plugged in but that sadly seems expected behaviour from other threads).

Nothing helps this - not even limiting the game to vsync, or the same framerate as it can get on battery. It keeps jittering around until the 140W charger is removed and i use a 60W charger at max.

This affects countless games - Helldivers 2, Planetside 2, Overwatch 2, Gunfire Reborn and and and.

What i dont get is how the gpu spikes this hard into frametimes worse than a 60W charger being plugged in, all while the Nexode is only delivering 100 instead of 140W (measured at the wall with a smart plug).

My first try would’ve been to enable amdgpu power limits and Limiting the amdgpu to 80W or 60W
echo 80000000 > /sys/class/drm/card1/device/hwmon/hwmon8/power1_cap.

It’d probably still manage to run just fine while keeping the laptop working wonderfully for me until a 240W charger makes it out of prototype phases - but sadly the card is limited (power1_cap_min is exactly 100W) in firmware, and sadly the linux kernel now also respects those minimum limits. While it allows me to give 120W to the card i’m not allowed to go below at all, sadly.

Same charger works fine for cpu+igpu only, which is my current “solution” to this issue.

So what i request of Framework is:

  1. Why does the machine stutter this hard and worse on a 140W charger than 60W, when it runs just fine on 60W pulling the rest it needs from the battery? And what can be done to fix it? (Note: Charge Limit is 60%, have not tested 100%)

and

  1. can you please allow me to limit the dgpu wattage, for highly efficient gaming on the go? Amd gpus can sometimes run at “most” (80-90%) of the framerate at like half the power limit if let be, which makes it a whole lot easier when travelling with just 140W (or having to deal with a friends leftover 60W when playing locally - and just imagine the size of future 240W chargers)
1 Like
2

Further research:

If i limit SCLK and MCLK to the lowest i get stable 30 fps. Since there’s only 3 levels i can sadly not limit it just fine-grained enough for this, but this is still worse than on battery or 60W.

Setting pp_power_profile_mode manually to VR has the least jitter, but it still has jitter. Other Profiles behave a LOT worse.

Putting the entire machine into “Power Saver” mode via performance profile daemon manages to stabilize it mostly, but at “same as on battery” performance level, not at “with wall power” performance level.

3

I was getting this on a UGREEN 140W brick too. Check your cable; when I was using the included 240W cable it was stuttering like this too (only very infrequently would it stop stuttering after a long gaming session, and I couldn’t reproduce reliably), but when I switched to a Cable Matters 240W cable I stopped getting the issue.

4

Okay, trying with tons of cables and … yes that was it. The included cable from ugreen had this behaviour as well as an anker usb-c cable rated for 240W - only a random ULT-WIIQ cable i had lying around fixes this behaviour for me (which is considerably thicker than the other ones).

Now it’d be interesting to know if this is on framework - or if the cables just have issues in some way despite being well below their rating here.

Framework, please test this internally if this is fixable or something weird going on, this is probably a really common charger as a “for now” until 240W ones come out.

Checking again - these might not have the EPR chip?

5

If the Anker cable is rated for 240w then it should definitely have the chip in the cable.

AIUI any cable capable of delivering more than 60W requires a chip. If the cable doesn’t have a chip then the charger and device limit power transfer to 60W.

6

It, specifically, is this cable from anker that is misbehaving with this charger. (The “240W cable” that comes with that charger also does not work.)

7

What power are you expecting the charger to deliver? The way I read the specs on that page suggests it may only deliver 65W per USB-C port, and another 10W from the USB-A port.

What power are you actually getting when using the cable that works with this charger?

8

Read the specs again, one of its ports, if no other devices are connected, can deliver 140W - and that is, with one of the cables i own, actually coming through, unlike both the anker and included cable (which both cause massive stutters when using the dgpu).

9

Moving this to general as this is hardware/brick related.

10

Moving a power brick thread here.

11

Update: Got a Cable Matters Cable and it behaves like the Anker one - but only on very high power draws, lower end games are fine one it. The weird Ult-Wiiq continues to behave properly.

12

I apologize that you made a purchase based on my bad info. I probably wrote down the wrong thing in the rush to join my friends in spreading managed democracy!

I just re-checked with four cables I have and both 240W cables from UGREEN and Cable Matters exhibit the stuttering issue. I noticed that both cause the system to constantly switch between charging and discharging.

Only when I switch to lower wattage cables does it stop, however with reduced performance and battery discharge. Oddly, while both of these are supposed to be 60W cables, one discharges at ~30W (another Cable Matters one) and the other just ~6W (Anker), both around the same FPS.

Written on the brick has voltages supported all the way up to 28V. I’m assuming it’s somehow getting stuck at a lower voltage, or switching between them for no reason? I can’t seem to figure out what it’s actually charging at, although I read somewhere that I need to actually have an inline meter to accurately tell. I think I’ll be picking up one and doing some better testing.

Here’s the links from my order history to sanity check:
https://www.amazon.com/gp/product/B0CCVPB4PC (UGREEN 140W+20W brick)
https://www.amazon.com/gp/product/B0BT8HPLS4 (Cable Matters 240W cable, stuttering)
https://www.amazon.com/gp/product/B09PB8DJ28 (UGREEN 240W OE cable, stuttering)
https://www.amazon.com/gp/product/B09G5S9T6V (Anker 60W cable, no stuttering, ~6W discharge)
https://www.amazon.com/gp/product/B0BT8HPLS4 (Cable Matters 60W cable, no stuttering, ~30W discharge)

13

At this point I’d just pick up the official PSU for gaming, and keep around the multi-port brick for travel. I’ll probably end up picking up a true 240W (or at least something higher wattage that 180W that’s multi-port).

14

I think your actual problem is the power supply. Note how the cables that work are 60W cables, which AIUI are the highest wattage allowed without chips in the cable. So the FW doesn’t request more than 60W, and the PS doesn’t expect to supply more than 60W.

But once you use a 240W cable then the FW will request maximum available, the PS will try and supply up to its maximum, but it sounds to me like you have found a problem that plagued FL13 machines where the framework didn’t ramp up the current but tried to draw maximum current straight off causing the power supply to go into overcurrent mode.

So have you upgraded the BIOS in your FL16 to 3.03? I suspect if you are still on 3.02 that the problem that plagued 13" machines still exists.

15

I am on the latest bios version, using the official flash tool from a usb stick to upgrade - and i do have this behaviour. Notably, all cables work fine on 60W and 100W ports - even of that charger. Only the 140W port is affected. I’ll test if the cable that doesnt show the issue can pull 100, or more, watts later.

16

Finally on Summer break, here’s the results from the power meter playing HD2 (standing in the spaceship):

I am running BIOS 3.03.

Cable Matters 60W, actual: 19.52V@2.69niceA, 52.5W
Anker 60W, actual: 19.2V@4.47A, 85.82W

Both of these are extremely stable readings, and fps is a flat 71.

The UGREEN 240W cable starts at 100W(23V@) and then raises to ~127W(27.38V), but after few seconds to a minute or so the meter cuts out and triggers power disconnect/reconnect sounds. This doesn’t happen when it’s plugged in w/out the inline meter.

The Cable Matters cable seems to disconnect much more infrequently (5+ mins if at all) but that might just be lack of sample size. The voltage is much less stable when it doesn’t disconnect, although fluctuations are around .5V, and sometimes 2V drops.

This meter Plugable USB-C Voltage & Amperage Meter for High Power Devices (240W E – Plugable Technologies doesn’t have a super high refresh rate, so I could sacrifice a cable and hook up an oscilloscope. Ideally there’s something in software to inspect what events the system experiences, but I can’t seem to find anything like that (at least on Linux).

17

@Woof did you ever actually try doing this?

I have amdgpu.ppfeaturemask=0xffffffff in my kernel parameters, but when I try to change this file even with root privileges, I get permission or disk full errors.

18

did you ever actually try doing this?

Yes, and, as mentioned, it would not let me lower the power target, only increase it to 120W. (this however did work fine)

But i’ve been testing with different 140W, 100W and similar chargers and i had everything from “charging stops entirely” after one particular 140W charger to my usual behaviour - and the one “working” cable is only going to 100W.

My current conclusion is that FW16 with dgpu does not work well with any 140W charger under load and i have to stick to the perfectly fine 100W port on my charger - which just limits high load scenarios to 3-5 Hours, depending on power draw, as it has to drain battery (and once it forces charging at 30% it dips in performance quite a bit).

Looking very forward to a future 240W charger being available personally.

19

Hey there, @Woof–yeah, it’s been a bit, I forgot I asked that. I wish I had read your message better, as I ended up finding the same things you learned. And thanks for some of this other context about the power block, as I’m super interested in that 240W to get moving as well.

Concerning lowering power1_cap, I did talk to folks (including Matt in this thread, indirectly) from the support ticket I made:

We use and recommend no power customizations per AMD specifically. AMD’s official recommendation is PPD which is enabled out of the box on Ubuntu 24.04.
If you’d like to try out other parameters, you are welcome to, but regrettably this falls outside of our support.
Appreciate that you have fiddled and discovered that 100W-120W is applicable, we will try to pass word and see if this can be lowered, but can’t promise anything.

I exchanged an email with AMD GPU folks and it turns out, “The driver limits the power caps to what was validated by the AIB or OEM.” So the responsibility is on Framework or their dGPU vendor to create a firmware update or a change to the dGPU’s PP table for this. A sufficiently brave user may be able to do it with the amdtweak tool, or study how it works.

20

As you might have noticed in the post too:

… yeah i’m aware of that for a while, since it also means i’d have to recompile my kernel for my tower all the time, where my previous RX480 (Now 7900XTX) saw significant efficiency gains from lowering it. That and the default enforced varibright (atleast that can be disabled with a kernel arg) since kernel 6.9 are two very sad defaults pushed from Amd.