Suspending a laptop does not shut it down. Rather it puts the components into a lower power state, and keeps power to the RAM so that your current session is retained. This is why when you lift the lid again, your session is immediately restored.
When your computer is shut down, all power is cut and the system is truly off. You will need to turn it on and the system will boot again.
So if your network adapter (wireless card) is continuing to receive power to maintain a wireless connection it is using more power than if it was not powered during standby.
When you considered that just maintaining a wireless connection is pointless if traffic received couldn’t be actioned, and so connected standby can also wake the system to process said network traffic, leading to more power use during standby.
@kaprests I think the reason why system76’s machine has decent battery life is that their machine and software is designed in a relatively close system (they don’t actually make the machines themselves but they can do specific optimizations) this is some what similar to what apple does. An operating system designed to work just on apple devices, which gave them so much opportunity to optimize that their phones so they run extremely fast with a lot less ram and battery demands. This is less likely on systems like Linux (or it’s kid basically Android), the kernel is usually configured before compiling to work for as much devices as possible out of the box (most of the “daily driver” distros do this) Which means turning on features that some laptops simply don’t benefit from or use at all (I don’t know if this affects battery life but for example you can turn both AMD and Intel support in the kernal on even though you would most definitely use just one platform at a time). Windows happens to behave in a similar pattern but Microsoft is doing a lot more communication with the laptop manufacturers than the Linux community to ship well optimized ISOs. That’s just from what I deduced over the years and I don’t got much sources. Just food for the brain I guess.
@Runkai_Zhang Yeah! I think what you are saying is the same point that I tried to convey. Most laptops are tuned by the manufacturer to run Windows, not Linux, and so one should expect that e.g. battery life may suffer on some such devices. I used S76 as an example of manufacturer tuning their machines to run Linux, to argue that Linux is not inherently worse performing with regard to battery life, it comes more down to the hardware support/tuning.
As you say, the same holds for apple, but for iphones/ipads and recently the M1 macs they also just happen to design better chips.
Empirically I don’t see the power draw in the top listing in Powertop after doing that, until I plug in an external monitor (fair enough), and it goes away after. For the moment I’m needing to do this after every boot but that is my ignorance of how to set these things persistently…
But upshot is maybe doesn’t need something rejiggered on the mainboard to at least paper over the issue?
ETA: With the change to the HDMI card power management, display brightness at about 10%, and having turned Bluetooth off, at rest seems to get ~4W draw at rest most of the time just eyeballing it. Amazed at @malachid 's result, considering the wifi is reporting 2.66W alone on mine!
BTW, the ASPM setting is critical, as powersupersave allows the package to reach down into those C10 idle levels. Without that it wasn’t getting below C3.
I’ve re-enabled hyperthreading, turbo boost is available. So basically stock BIOS settings otherwise.
With that configuration I’m getting down to 2.6W idle. Before applying the ASPM setting I wasn’t getting below 4-5W.
My prior testing showed in Powertop’s Tunables section turning on (toggling to Good):
Autosuspend for USB device HDMI Expansion Card [Framework] which is: echo ‘auto’ > ‘/sys/bus/usb/devices/3-4/power/control’ (3-4 for me since my card’s plugged in the front left port)
did nothing.
I just tested this again to see perhaps if any Powertop/kernel updates changed anything, issue remains.
Are you sure this is actually working? Powertop sometimes doesn’t accurately list power draws in the Overview tab, as they’re just estimations.
Although it may disappear from the list in the Overview tab, the actual total discharge rate remains the same. Upon physically un/plugging the card, total discharge rate -/+ ~1W.
Thus a more accurate way would be to measure the delta in the power draw with the HDMI expansion card plugged in vs. not.
So let the laptop idle with the HDMI expansion card plugged in, get discharge rate. Unplug HDMI expansion card, get new idle rate. And then do the reverse for more data/accuracy. Compare numbers.
Anecdotally, it can takes a few seconds for the power draw to stabilize when un/plugging the card. Note: Powertop has a default refresh interval of 20 seconds, and one can change it by pressing ‘s’.
Also, testing on both Fedora and Windows is a good sanity check.
Side note, Brad from Brads Hacks noted the microsd expansion card exhibits the same behavior (I don’t have this to test):
Interesting, do you have PSR (Panel Self Refresh) enabled? With stock BIOS settings, idling the system should reach C8 states. C10 was only reachable with PSR on in my testing (saving ~0.5W at idle, with little screen updates). And PSR is unfortunately, currently broken edit: on Linux, I forget if on Windows.
I sure do, and I haven’t experienced any issues with it running the 5.12.19 kernel. I understand people are seeing stuttering or flickering, but I haven’t noticed anything.
I am definitely seeing minor, transient visual artifacts but I haven’t tested to determine if that’s due to PSR or some other issue.
Entirely fair question, my testing methodology is certainly unsophisticated and this could well be voodoo. My sophisticated experimental protocol involves planting the Framework to my left while I’m working on my desktop to the right, randomly peeking at the Powertop screen probably every couple of minutes over the span of about half an hour, and making a mental note of the total discharge rate and the biggest offenders
I first noticed the entry for the USB Device HDMI expansion card in the list in the ~900 mW range with total usage around or just shy of 5W fairly consistently over the span of probably about half an hour, then after making the powertop-recommended change the entry consistently disappeared from the list (it was never totally consistently on it in the first place), and the total usage dwelled in the low 4 Watts.
Quite happily, making the changes @Brett_Kosinski suggested to the TLP parameters yielded about 2.8-3W idle! Which is a little funny to see when the top two entries are 2.69 W and 878 mW, but presumably this is reflecting what you said about the numbers being an approximation.
Pulling out the HDMI expansion card maybe decreases it a little bit to the 2.6-2.8 W range. Then putting it back in returns the system to the ‘off’ state for […]/power/control and the total usage goes to 3.5-3.7 W, with the USB Device: HDMI entry logging in the 700-800 mW range. Then putting the power control for HDMI back to ‘auto’ goes back to 2.8-3.0 W.
So tl;dr, it looks like at least under certain conditions the powertop-recommended change to the HDMI card power management takes a decent chunk of the power consumption, but there is some more yet to eke out somewhere else in the system.
@Michael_Lingelbach Yup! Gnome 38 (since that’s what Debian testing is still shipping) on Wayland. Maybe the issue is occurring but I’m just not noticing? How does it manifest?
@Michael_Lingelbach Have not fiddled with the PSR yet, I’m a little nervous since I get some error/warning messages as is about i915 that are currently beyond my ken, but after a few more experiences with rolling back will hopefully get to be confident enough to give it a whirl
PSR should be enabled by default, there are many reports of it causing issues like stutter/lag (the arch wiki recommends disabling it, but the linked issues are extremely old forum posts), but it is a power saving feature so disabling it does impact battery life (consensus seems to be about 0.5w)
@A_L thank you for taking that time and your detailed write-up, I pretty much do the same!
I went back for some more detail, and noticed something strange.
With the HDMI Expansion Card plugged into the Left Rear (LR), Left Front (LF), or Right Front (RF) slots:
Fedora idle with no expansion cards: ~2.6W.
Idle without autosuspend: ~3.7W
Idle with HDMI USB auto suspend tunable: ~3.4W
However, plugged into the Right Rear (RF) port sees:
Idle without autosuspend: ~3.7W
Idle with HDMI USB auto suspend tunable: ~2.9W
So in Fedora, LR, LF, RF slots see:
~+1.1W without autosuspend.
~+0.8W with autosuspend.
The Rear Right slot, however, seems to consume less power, with only a ~+0.3W increase with auto suspend. My Right Rear consumption seems in line with your findings @A_L. Which slot do you have your HDMI card plugged into, and can you test your other slots?
Edit: Important info I forgot to add, might give some clues?
On all slots but my Right Rear, when I insert my HDMI Expansion card, I get this error:
dmesg:
Card still functions normally. Inserting into the Right Rear slot shows the same initial message but without the red error sentences and attempt to power cycle.
On the Windows side: idle with no expansion cards: ~2.4W.
Idle HDMI card in LR, LF, RF slots: ~3W
Idle with HDMI card plugged into RR: ~2.7W
So in Windows, HDMI in my RR port consumes just ~0.3W less than the other slots, and another ~0.3W vs. HDMI card not plugged in.
tldr, for me:
Fedora: with auto suspend, HDMI card in Right Rear slot consumes ~+0.3W. All other slots consume ~+0.8W. Without autosuspend, all slots consume ~+1.1W.
Windows: HDMI card in Right Rear slot consumes ~+0.3W. All other slots consume ~0.6W.
tldr of tldr: HDMI card seems to draw extra power. Right Rear slot seems to draw less power than all other slots.
Some good news regarding PSR though!
For me, it caused noticeable stuttering in Fedora in both Gnome40 and Sway. Simply typing in a terminal the text would stutter very badly. Constantly moving the mouse cursor around, I would see freezes every few seconds or whatever, jarring and annoying. Issue wouldn’t occur if graphics was being used, say watching a video in the background.
I too read that thread yesterday, and decided to try out 5.14. Pleased to report that I don’t see the issue on Fedora 34 5.14.0-60.vanilla.1.fc34.x86_64 kernel! On Windows PSR seems fine as well.
This means that Linux Fedora and possibly other distros can now see the PSR energy savings (at least ~-0.5W) and hit C9/C10 states, without the micro stutters.
Now I’m going to go pickup my 2x32GB 3200mhz kit in the mail and see the comparison vs. current 2x8GB
@Tyler_S you need to led powertop run until it’s collected sufficient samples to infer per-device usage. You can just let it run in the background on battery for a couple hours and the numbers will show up (powertop --calibrate will make them more accurate). In practice, the display power draw is never estimated correctly.
The overview tab lists the top power consuming items which keep waking a processor from its idle state. When tuning applications and device drivers for power, the idea is to reduce the number of wakeups/second to maximize the system’s power performance. This tab shows the usage, number of events, category, description, and power estimate of the most consuming power items in the system.
Here’s some personal power consumption data from my quick/rudimentary tests on my i7-1165G7 between:
[1] 16GB (2x8GB), 2133MHz: SK Hynix (timings too lazy to look up/verify) 1.2V model: HMA41GS6AFR8N
tldr: seems like [2] definitely consumes more power. Note size, MHz, and timing differences, so unfortunately, I’m not sure what combination (GB, MHz, timings, chips, etc.) is affecting what. See below for the data.
Sidenote, my 3DMark Fire Strike score by 2-300 as expected, probably due to 2133MHz → 3200MHz.
Data for this round of tests, lowest power draws recorded, no expansion cards plugged in:
[1] denotes 16GB 2133Mhz set, [2] denotes 64GB 3200Mhz set
Idle test: PSR on, 10% brightness, wifi/bt on
Video playback test: 720P version of Tears of Steel: Download | Tears of Steel, what PCMag uses to test shrugs
Speaker volume: ~50-75% (was too lazy to control, please forgive me)
Fedora: MPV using VAAPI hardware decode
Windows: Microsoft Movies & TV / stock Win10 media player
Fedora (I’m currently using TLP with @Brett_Kosinski’s config (thanks!), though at some point I may switch back to power-profiles-daemon. Both have seemed good, as it really depends on how governors/profiles etc are set. Note I’m also currently using a non tested 5.14 vanilla kernel, which seems better battery wise vs. 5.13?):
Idle test [1]: 2.2W (this is the lowest I’ve seen. It was 2.6W on kernel 5.13)
Idle test [2]: 2.6W
Video test [1]: 5.2W
Video test [2]: 6W (not sure why this is so much higher. Though I was getting 6W with [1] on kernel 5.13. Meaning [2] on kernel 5.14 is matching [1] on kernel 5.13. shrugs Take that as you will, maybe the 2133MHz → 3200MHz jump is causing more gpu power draw? Maybe it’s due to what I ate for dinner, shrug shrug shrugs)
Windows (battery saver profile):
Idle test [1]: 2.7W
Idle test [2]: 2.9W
Video test [1]: 5.2W
Video test [2]: 5.5W
Some extra general Linux (Fedora)/Windows battery life findings:
For idle/video playback battery life, Linux Kernel 5.14 seems close Windows. Maybe slightly better, maybe slightly worse. For video playback, ensure that hardware decoding is being used for best battery life. Makes a big difference.
On Windows, for YouTube 1080P playback, Microsoft Edge with Efficiency Mode on, I’m drawing 5.5W which means that the laptop can run for 10 hours with the 55WHr battery…well at 10% brightness. Maybe realistically/easily 8-9 hours with higher brightness. Not too shabby! This should be about the same on Linux with browser hardware decoding, but I haven’t been able to get the experimental feature flags working in Chromium/Edge on Fedora, yet.
