Keeps jumping around. Now it mostly says “Charging”
1 Like
I think you are seeing normal behavior. I’ve seen a few other posts asking about the same thing. I think the “answer” was that the system can draw from the battery in addition to the usb supply during high demand and switch back to charging the battery when the load goes low. A combination of immediate CPU usage and power draw from other system components and usb devices etc.
I suspect also that the charge controller may be switching between modes while “maintaining” a charge.
I think you may be right. I saw it go to “Not Charging” for a little bit. The thing is it still says Discharging/Charging even when Idle. I only had the single browser tab open to make my posts.
Oddly when I did not have the limit set i did not see this behaviour and it was always at Not Charging.
Just want to make sure I am not killing my battery as I will be getting a dock soon and replacing my desktop with the FW. So still learning about proper battery maintenance.
2 Likes
The tool @Fleetscut mentioned (gnome-power-manager) also shows the charge and discharge rates of the battery over time.
This is my battery over the last few hours. Even though gnome also shows “charging” to me (and cycles between ~“nothing” and ~“charging”), the rate is 0 most of the time. There are some spikes in the graph, where my framework might have had some heavy load.
2 Likes
I added it to the wiki post, but I’ll add a comment as well to bump this thread: There is now an official battery optimization guide for Ubuntu. See the link above.
3 Likes
It’s in the first post.
2 Likes
I’ve followed that guide, which includes running TLPUI which wasn’t able to actually save the file here. I applied the diff by hand and published a copy of the patch for your convenience, see https://anarc.at/hardware/laptop/framework-12th-gen/tlp.patch
1 Like
Yeah it looks like TLPUI is hardcoded to change the /etc/tlp.conf…which means it may get nuked anytime you get a major version update you should really set up a /etc/tlp.d and create numbered tlp config files there i.e. /etc/tlp.d/10-hostname.conf or 10-name of tlp snippet you are configuring and so forth. If you read tlp.conf file this is the recommended method. Leaving the /etc/tlp.conf for the default settings only to be modified by the snippets you choose to modify. Much easier to read it in small chunks/files vs utilizing a GUI that might break things under the hood.
1 Like
I agree @nadb for intermediate to advanced users, rolling a custom config is a solid option and I do usually edit it my hand.
However historically, I’ve found over the years asking newer users do not want this approach and prefer a GUI, despite massive update overwrites. I saw a lot of this at my previous job. So I opted for the lesser of two evils.
Massive TLP update happens, guide is updated, newer users follows along again. 
Granted, it’s slow, but it’s easier for some folks.
You’re correct, I need to make sure users have access to the official docs to decide which approach is best for them.
3 Likes
@Matt_Hartley In the official guide: ppa:linuxuprising/apps is not safe as it is not official PPA
1 Like
Can you provide a link to this claim? Thanks
My research has indicated it is not unsafe. I know the AUR package changed hands, but can you elaborate with additional data?
My research indicates it’s fine unless you have a link to something that indicates differently, then I would be happy to change it.
At some point when I clone myself , I will be rolling our own PPA for this and a few other things. At that time, I will be doing our own builds of this and other applications, build flow/source provided for inspection of course.
6 Likes
The best recommendation is to keep only expansion cards you need while on battery. For most people, this is going to be 2x USB-C expansion cards or 1 USB-C and 1 USB-A cards so you can connect to devices periodically
Is this correct suggesting using only 2 cards? Presumably the USB expansion cards are totally passive, and 0,2 or 4 makes no difference?
The quoted suggestion is worded a bit weirdly, but in response to this presumption, the USB-C cards are direct passthroughs, but USB-A does have some power draw. As such, 4x USB-C would be zero port power draw.
4 Likes
This is interesting - I had always assumed that USB C - A was totally passive!
The card itself is, but it keeps some mainboard subsystems powered that are able to go to idle while not in use on a usb c-c card.
6 Likes
That’s amazing. How many metaphorical limbs did you have to cut off to get this?
1 Like
My linux battery life is terrible. I consume 10+ watts on a light load, idling closer to 7 watts. Battery life is, accordingly, around three hours. Here are some of the things I’ve tried:
- powerprofilesdaemon, with power saver mode.
- Disabling cores and messing with the multiplier in UEFI.
powertop --auto-tune- Changing “perf-bias” with
cpupower -
tlp, with power-saving tweaks to every setting I felt I understood enough to change:CPU_MAX_PERF_ON_BAT=20,CPU_BOOST_ON_BAT=0,CPU_HWP_DYN_BOOST_ON_BAT=0,PCIE_ASPM_ON_BAT=powersupersave. I have confirmed this service is running. - Removing expansion cards.
I use EndeavourOS (arch) with KDE. What’s more concerning than the high power usage is that none of the above things really seem to change the power usage. Here are some potentially useful readouts:
-> inxi -C
CPU:
Info: 12-core (4-mt/8-st) model: 12th Gen Intel Core i5-1240P bits: 64
type: MST AMCP cache: L2: 26 MiB
Speed (MHz): avg: 810 min/max: 400/4400:3300 cores: 1: 792 2: 1000 3: 882
4: 514 5: 1000 6: 1000 7: 811 8: 1000 9: 679 10: 571 11: 698 12: 674 13: 661
14: 1000 15: 684 16: 1000
-> cpupower frequency-info
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 4.40 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 1000 MHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 869 MHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
Any help would be appreciated.