It has been a while but I had tried various experiments regarding battery/charge level and nothing fixed the issue other than changing to a different power adapter.
Valve is saying that about their new Steam Machine specifically, which has separate dedicated graphics memory in addition to a single system ram stick. Totally different situation than a laptop with dynamically shared system ram.
1 Like
Suppose I find out that it is the battery flipping issue – what would be the next steps? Is there a specific configuration of charge limit / on-battery / power mode in Linux that is guaranteed to work if I’m affected? Or should I just try every combination of choices you asked and if something works that’s great and if nothing works I’m screwed. I’m not really sure what I’m doing here and it’s genuinely a really big time sink to run all these tests over and over.
Was this a DIY build?
Yes. Specs mentioned previously in the thread. Ryzen™ 7 7840HS, DDR5-5600 - 32GB (1 x 32GB), 180W Power Adapter.
It does? I thought that given it was an APU it shared the vram with the CPU.
I have that issue on my device. What I’ve done to mitigate it is use balanced profiles instead of high performance, and use a 240W. Basically, I try to avoid pulling more power than the PSU can provide so the battery doesn’t drain too much.
Find some benchmarks people did of the config (cpu), you do the same benchmarks. Then you might be able to pinpoint the bottleneck or culprit part causing performance issues. The temp seems fine.
I lean towards the single channel config being the main issue, but a benchmark compare might clear that up.
And the ssd? Not all ssd are made the same, some have fast cache and indexing controllers and such greatly improving performance for random access and sustained throughput. And heat on the nand chips could also cause issues, did yours come with a slab of heat transfer material?
I would also suggest to contact the framework support, I can imagine they might have dealt with such case like that before and have something in their internal KB articles.
16GB DDR5 + 8GB GDDR6 VRAM
Up to 4k gaming with FSR 4.1, thanks to a discrete semi-custom AMD desktop class CPU and GPU.
1 Like
So, I actually tried running Satisfactory on Linux and noticed that it’s a bit odd.
- By default, it runs in Windowed Fullscreen and won’t change the screen resolution. Switching to exclusive fullscreen breaks everything, and the windowed setting is weird but I did manage to get it into a 1920x1080 window eventually…
- The default fullscreen resolution was a random resolution higher than my monitor’s actual
- When running fullscreen, my CPU was capped at 1.4ghz and fps stuck around 20 on low with FSR turned on
- The game initially boots in DirectX 12 mode and there is an experimental Vulkan renderer, but I can’t get the game to load if I turn on Vulkan mode
- In the 1080p window, the CPU boosts over 4 Ghz and I get 70-100 fps on low settings with FSR turned on
- Regardless of the screen resolution and CPU frequency, I don’t see any stuttering, and my frame time graph is nice and smooth
This is all with 140 watt power delivery because that’s what my monitor delivers, but that shouldn’t make a difference without a dGPU in the mix. I also have 2x32GB SODIMMs installed with the gaming option turned on in the BIOS so that 8GB is dedicated to the GPU.
So I still think the stuttering might be RAM related, but Satisfactory maybe also has some sort of problem with fullscreen performance on Linux/Proton.
Edit: I was able to reproduce the CPU not boosting with other games that are GPU bound (constantly at 99% utilization). So I think that’s just down to fullscreen Satisfactory insists on running at 4k+ and the iGPU obviously is not cut out for that. CPU load is only ~15% in these cases
I have been in conversation with support and they only suggested me try a bunch of dead ends such as switching OS and eventually switching the power supply which I have been satisfied with for now because the spikes go away, but performance is still subpar. I booted up Satisfactory again today and for some reason it was running at 15 FPS instead of the ~30 it was running a few days ago.
SSD being the culprit seems bizarre to me. The SSD is taken out of my previous laptop that this F16 replaced.
I’m persuaded that an additional RAM stick would help, so I will be looking into pursuing this option.
All in all I’m pretty disappointed in this experience, micromanaging the power supply is not an issue I ever would have imagined myself needing to deal with. I’m strongly considering just getting a more reliable machine than this.
From what you have said so far, the “battery flipping” is the most likely problem.
I wrote some special EC code to get round the problem, but that EC does not work with the latest BIOS.
Essentially the problem is that the cpu can, for short peak periods, draw more power than the power adapter has, and thus pulls it from the battery. After a while the battery gets low, so it tries to charge it. This diverts 80W to charge the battery, and forces a reduced power profile for the cpu/gpu, thus stutter.
My EC code simply made it not try to charge during a game.
You can see if if is charging or not from using “sudo ectool chargecontrol”
Idle == not charging
Normal == charging.
Discharging == discharging
You want it to stay in “idle” during a game.
It appears the charger has a
- “battery supply additional power when needed” mode,
but does not have a
- “charge battery with only excess power when cpu/gpu not using it” mode.
I think it is a hardware design problem. You need different charger chips to do (2).