If there’s one thing you want from a laptop, it’s long battery life. You want every drop of power you can get to work, read, or just be entertained on a long jaunt. So it’s good to know where your power is going.
You can use the powertop utility to see what’s drawing power when your system’s not plugged in. This utility only runs on the Terminal, so you’ll need to open a Terminal to get it. Then run this command:
sudo dnf install powertop
powertop needs access to hardware to measure power usage. So you have to run it with special privileges too:
The powertop display looks similar to this screenshot. Power usage on your system will likely be different:
The utility has several screens. You can switch between them using the Tab and Shift+Tab keys. To quit, hit the Esc key. The shortcuts are also listed at the bottom of the screen for your convenience.
The utility shows you power usage for various hardware and drivers. But it also displays interesting numbers like how many times your system wakes up each second. (Processors are so fast that they often sleep for the majority of a second of uptime.)
If you want to maximize battery power, you want to minimize wakeups. One way to do this is to use powertop‘s Tunables page. “Bad” indicates a setting that’s not saving power, although it might be good for performance. “Good” indicates a power saving setting is in effect. You can hit Enter on any tunable to switch it to the other setting.
The powertop package also provides a service that automatically sets all tunables to “Good” for optimal power saving. To use it, run this command:
sudo systemctl start powertop.service
If you’d like the service to run automatically when you boot, run this command:
sudo systemctl enable powertop.service
Caveat about this service and tunables: Certain tunables may risk your data, or (on some odd hardware) may cause your system to behave erratically. For instance, the “VM writeback timeout” setting affects how long the system waits before writing changed data to storage. This means a power saving setting trades off data security. If the system loses all power for some reason, you could lose up to 15 seconds’ of changed data, rather than the default 5. However, for most laptop users this isn’t an issue, since your system should warn you about low battery.
Activating AutoSuspend for USB is a bad idea if you”re using an USB-mouse like most notebook users would do.
Paul W. Frields
That’s quite true, although it’s debatable whether most notebook users use an external mouse. Many do not. That’s why I advised trying different settings first. Thanks for the example!
TLP and the like allow to whitelist USB devices by ID or by type to avoid this type of behaviour. So I’d still recommend powertop and monitoring tool and TLP or laptop tools as power-saving tool, since they allow for much more granularity.
Agreed, TLP is much better, especially because you can tweak both battery and AC power modes.
TLP even whitelists all input devices by default, so it’s plug and play for most people.
powertop2tuned is way more effective. Also, with powertop2tuned I can uncomment at will, after testing what works and what doesn’t work with powertop.
I’m with Heiko here. Even people who don’t use external mice or keyboards when on the road, most plug it in when in the office. Really wished powertop had a way to tell it to remember my good/bad settings and re-apply that during bootup (i.e. with –autotune) instead of setting everything to good.
Of course, powertop tells you which commands it’s using to tune things, so you can automate it…
Would love to have also an easy way to switch from performance mode to save power mode.
Also, are this settings active also when computer is plugged with power cable?
I mean, sometimes is good to have power save, but sometimes I just want performance from the peaces of hardware that I’ve payed so much for…
And make easy to switch the setting from one way to another would be fantastic
Does this clash with TLP?
Paul W. Frields
Since both are twiddling kernel settings similarly to /proc, presumably one would overwrite the other’s settings when run. Since service ordering may not be fully deterministic in systemd, you might get different results per boot. So I wouldn’t recommend using both. Note also that TLP is more complex and configurable. For many users this is unwanted. Others prefer it. 🙂
Interesting utility. I tend to use a USB Logitech TrackMan Wheel rather than a mouse with my notebook. I find it easier than the touchpad which I hardly ever use because I have better control over the pointer that way.
I might give it a go though plus the alternatives mentioned in comments, at present my notebook gives about 3 hours on battery life under Fedora 22 which is not great compared to what it will do using the manufacturer’s power profile in W8.1 (almost a full working day). The notebook was purchased new in February and has an Intel Core i3-3110m processor and an HM75 chipset. No discrete GPU, just the onchip Intel HD graphics.
Generally, though I have the power adaptor to hand and can plug in as needed.
In this case, which options would you change too Good?
Could we start listing some options we should usually change, too get better battery life, which I think is the worst thing Linux has in laptops?
Thanks a lot
Ubuntu installation command?
It is fedora site not ubuntu … lol but maybe sudo ap-get install powertop … btw…. google your friend
Well, that’s nice. It appears that the blog ate my post:/
The state of desktop Linux pm is pretty poor, and, perhaps arguably, the biggest impediment to wider adoption that the community can actually do something about. When you read reviews on non-linux specific sites you always see the same thing: ootb battery life sucks:)
As others have mentioned, we have daemons like tlp and tuned, but they can almost certainly be improved. For instance, before suspending the system, the daemon would be triggered to put the devices into their standard ootb states, and simply reverse the process when coming out of suspension (i believe tlp has hooks for this, and certainly systemd has its pre/post suspend jobs).
Similar to our First Boot tutorial, we could offer up to the user the option of running an automated test (similar to what is done during Test Days, but with a FAR larger audience — and no, i don’t think there’s an effort we could make that would increase the number of Test Day participants to the levels we’d need). There are a number of ways to actually test the hardware, including offering up this option BEFORE they even install, by including it on the live-image. Depending on the results of these tests, we can suggest different levels of power savings with different levels of risk. Obviously there is lots that can go wrong, and if they go on to taint the kernel, they’re gonna have a bad time. These are, however, “just” implementation issues. Tricky ones, but not on the face of things insoluble (as opposed to fixing everything pm related in the kernel for all hardware would be).
The other part of this is building a hwdb. This would be really useful. For one, we can employ it to supplement our decision making process regarding per user power saving settings. Look for buggy combinations of hardware and stability regressions. Used in conjunction with bugzilla, it could make the tracking down of tricky hardware bugs somewhat easier. At a minimum, it would act as a knowledge base that isn’t locked in the heads of a few devs.
Building the hwdb can be done in a couple of complementary ways. One, if the user decides to run the hardware test we can ask them if we can store their anonomized hardware/firmware/driver data. Two, using bugzilla as a source of both good (or at least not obviously bad) and buggy hardware/driver combinations. Getting this data will be pretty tricky, might not be too useful, but it’s a potential massive source of the kind of infon hwdb needs.
Before any of that is done, however, choices need to be made.
Do any of the existing dynamic power management tools for meet our needs? If not, can they be made to do so?
How do we decide what’s acceptable risk? Can we present the information in such a way that the user can make an informed choice?
This should be a cross-desktop effort, but those tend to make even comparatively simple tasks Sisyphean. So, should many of these, and no doubt other, decisions be made prior to engaging with the larger community? What state should the project be in before presenting it to them? Given the history of these things, I’d suggest a two step process:
1) probe for interest from various leaders in the other distros and then branch depending on what we hear
2) If there is interest, and a specific direction can be agreed upon, then we | go from there
2) Otherwise keep it fedora-only for the time being (i believe this is the most likely outcome)
If the rest of the Linux community isn’t interested in this, it could become a very big differentiator for Fedora. If they are, all the better for the end result.
There’s a lot that can be done here to improve things, and leaving things as they’ve been doesn’t seem to be helping matters much. Yes, there are loads of problems but i think the problem can be made onerous for users without the risks overwhelming the benefits.
PS: I’m probably going to submit some form of this proposal to the mls, or at least get the temperature of the room. I’m also considering just doing some of this work to at least see what is currently out there. If nothing else, that will give me actual data to include in a more formal document.
If anyone is interested in this, let me know.
I use powertop service and have to re-plug the external mouse after booting so that the power saving setting is not applied to it. The rest just works fine.
powertop doesn’t seem to affect my logitech M570 Trackball with all the toggle options set to good. It boosts the battery life by around 30 minutes over default fedora settings. so a little gain but not massive inroads.