if there are software mitigations possible then it’s likely kernel configuration and daemon setup can affect these. Can you list what you’re using? (TLP, kernel version, distro, perhaps how much has been tweaked from standard configuration)
can you clarify for each entry or each table whether the results are for ‘deep’ or for ‘s2idle’?
can you clarify if with ‘idle’ you mean ‘system on but minimal activity’ (screen blanked/locked perhaps) or whether you mean ‘s2idle’ suspend?
The kernel is the latest in Debian bookworm, which at the time of writing, is 5.19.11 I believe. See this page for the latest.
I have powertop autotuned, tlp.service running, and tried every trick in the book you can see in this review.
I thought the table was pretty clear, but unless otherwise noted, all tests are done in deep mode. The second and third lines are the only ones in s2idle.
I guess that is a little ambiguous, but you should assume “idle” means “computer powered on but not doing any special processing” and “s2idle” means “computer suspended in s2idle mode”. If you could spot more precisely which place is ambiguous for you, i’d be happy to fix the summary.
Thanks. The main ambiguity to me was whether the difference in marginal power use for USB-A was between deep and s2idle or between deep and idle. From what you describe it’s the latter, and s2idle would likely show a similar margin as deep.
In a way that makes sense if indeed something in the cards prevents something internal on the motherboard to power down properly.The motherboard component is probably supposed to be on whenever the system is on (also when it’s idle), so the difference only really shows when suspended (with deep or s2idle).
Your figures also suggest that 12th gen motherboard is significantly better for suspend, or that recent kernel development has significantly improved suspend power usage.
I see. Yes, the difference in USB-A power usage is really between suspend and runtime. Adding a USB-A card while the machine is running takes up an extra 10mW, while adding it during sleep (deep, haven’t tested with s2idle specifically) takes up hundreds of miliwatts (300-500mW).
Update: I have tried to clarify by adding a comment under the table, and by ditching the ambiguous “idle” in the conclusions.
Ah that’s an interesting theory. It would explain the difference between one USB-A card (+500mW) and 2/3/n USB-A cards (+360mW each).
Still, the extra 140mW there (500mW for one minus 360mW for additional) is less than the cost of a single one, so I can’t help but wonder that there’s something specifically bad with the USB-A firmware.
Ah, that’s really nice to hear. It would be interesting to see you test the latest kernels to see if you can get similar results as mine in the 11th gen.
Awesome testing, and glad that batterylog was useful. BTW, for shutting off USB here’s a thread w/ a script that another user built that may work for shutting off USB devices on suspension: [Guide] Automatically disable USB devices for battery savings
Sadly, I don’t think this will work for the USB-A ports, as they don’t show up in lsusb at all afaict. I believe that there’s probably something going on with those plugged in that are keeping the TB4 active when it shouldn’t be or something. @nrp mentioned that the Framework Chromebook was able to pass Google’s battery requirements of 14 days of standby and that they learned a lot about Intel’s [Burnside Bridge TB4] re-timers and that this improved behavior is being backported as a firmware update.
14 days == 336 hours. If it was able to pass that test, on a 55Wh battery, that means that the Framework Chromebook was able to average <163 mW of power drain while in suspend. (I’m also really interested in whether an updated firmware could really get the Framework to >10h of active usage - that would be <5.5W avg under whatever Google defines as “common tasks”).
Thanks, I hadn’t seen that thread (so many threads!). I guess that won’t work for the SSD card since that would crash the filesystem (assuming you can’t unmount…) But still worth a shot.
It’s really too bad because fixing USB-A is my primary objective here… If i can’t turn off those cards, it means I need to swap them in and out all the time, which makes me wonder what the spec is for those expansion ports, in terms “how many times can i put things in and out until it breaks apart”… I bet it’s not as good as we might like!
This is what is so frustrating here; it looks like the Framework team did figure out a lot of that stuff, but it’s being kept somewhat secret or at least in limited distribution (e.g. to the Chromebook version).
Is the firmware update you’re refering to the DisplayPort beta or is it at the system level?
I’m not that far from this metric in my tests: with everything turned off (well, with USB-C cards, actually, turns out that helps, weirdly), i’m at 0.23W or 230mW… So close! It’s 10 days, which, for my use case, is pretty good… The problem is the second I add anything on there (and especially USB-A, which I use on a daily basis), it crashes down to 3 days (or explodes to 1W+ depending on your perspective)…
I bet it could. I can actually get > 10h by tweaking stuff a bit and holding my breath while powerstat runs. My original power tests gave me 2.5W idle (no cards, again), and I’d typically see 6-9W usage under moderate load (includes playing music, for example).
But start doing anything though, and things go sort of bonkers… I haven’t tested playing videos with, say, a simple player like mpv, but playing videos in Youtube already jumps you past 9W easily. Playing music in a web player like Navidrome threw me up to 12W… So yeah, tricky stuff, power management: you need to manage the entire stack otherwise you leak everything like a sieve everywhere.
I don’t think it’s being kept secret just that it’ll take time to backport. Also, I think you’re looking at it from the wrong perspective - the Framework team learned (presumably undocumented, or at the very least non-obvious) tips and tricks from Google’s more experienced team during the course of co-development - stuff that they might never have figured out otherwise (Google has the learnings from having released dozens of devices with basically every single major OEM over the past decade+). That Framework is now able to take these learnings and improve their core products is a huge win.
Yeah, I could get it down to <2.5W on console idling doing absolutely nothing (ready to advertise >20h of battery life, lol), but as soon as you get out of spending 99% time in C10, power usage skyrockets. Even idle at C8 seems to draw 4-5W. For very light usage (text typing, very light web pages) I can average under 10W, but video playback (mpv of yt-dlp’d videos or YouTube w/ VA-API acceleration) are all >10W at 200 nits.
Good point. It just feels like the non-Android Linux users are often left in the sidelines here. But you’re right, a lot of this good stuff is trickling down to us, even if Android is really not Linux all that much.
That sums up my experience as well. Is that with the 12th gen?
Update: just browsing around lightly, editing files and reading/answering mails in Emacs looks like this:
Interestingly, playing a video in a (720p) window in a window takes up more power (10.5W) than in full screen (9.5W) but I blame that on my desktop setup (i3 + compton)… Not sure if mpv hits VA-API. Similar results with 1080p, interestingly, except the window struggles to keep up. Full screen fine, and at a comfortable 9.5W, which means a solid 5h+ of playback, fine by me!
Update 2: Fooling around the web, small edits, youtube-dl, and i’m still at around 80% battery… i had a 7h remaining estimate before I started goofing around Discourse, so I suspect this very website is a pretty big battery drain, actually. I see about 10 W, while I was probably at half that just playing music with mpv in the background…
Confirmed: it looks like editing this website in discourse takes a solid 4-6W. Amazing.
I don’t think that is a problem, because the USB c port doesn’t need to hold the cards. The plastic lock holds them in and if that wears out, then you can just replace the plastic piece.
Awesome testing and beautiful write-up! Only thing I’d add is that I assume you did your testing on BIOS 3.10, but it would be nice to have that noted in your post. I’d also love to see if the DisplayPort Beta firmware does for your results if anything. Either way, thanks for doing all this testing and sharing your results with the community!
I would assume that the USB-C socket itself has a limited lifecycle. Sure, you can replace the whole case or tweak it, or replace the card, but if the USB-C socket itself gets screwed, you basically need to change the whole board.
That’s an excellent question, and I don’t think so! The 12th gen, from what I understand, ships with the latest BIOS version, there is no available update, at least. Mysteriously, however, it seems I’m running version 3.05, not 3.10:
anarcat@angela:~$ sudo lshw | sed -n '/BIOS/,/version/{/version/p}'
version: 03.05
Even more bizarre, the above BIOS information page says the latest version is… 3.04!
That said, it seems you might be talking about the 11th gen BIOS, which does have a 3.10 release… It looks like those are two different BIOSes with different release cycles…
Update: I added those details to the post anyways.
… so do I, but unfortunately I don’t have the means to update the firmware on that card here (no Windows, nor do I want one). I’d be happy to test an updated card if shipped, same with the ethernet card or any other card people would fancy.
While ChromeOS is it’s own slightly closed offshoot, it’s actually much closer to “Linux” than Android - it runs much closer to mainline kernels w/ lots of upstream interaction (currently on 5.15), and is built on Gentoo/portage+chroots (w/ a custom DE, but not a completely custom userspace). Android apps on Chromebooks are actually run through a container (ARCVM).
Yep, a 1260P w/ 2x32GB DDR4-3200 and a 4TB Phison PCIe4 Gen4 drive.
There’s the detail I missed! Didn’t realize this was on the 12th gen board! Thanks for clarifying. They do indeed have separate BIOS versions for the two laptops.
So glad to see it always good for future users to have this context if they view your post in the future!
Thank you for doing this detailed testing on expansion cards @anarcat, very much appreciated.
I was aware of issues with HDMI, Displayport, MicroSD and storage cards having high power draw, which is why I only ordered 1 HDMI and 1 MicroSD expansion card for occasional use.
USB A using any more power than USB C is very disappointing to see. I would love to understand why this might be the case.
Perhaps someone with more electronic expertise can provide the appropriate references. From what I understand, the power delivery protocols between USB-A and USB-C are different and while there doesn’t need to be any active electronic components in an adapter, a USB-A adapter needs to connect some leads with a specific resistance in order to signal that power may need to be provided. From what I understand, having that connection forces something in the USB-C interface on the motherboard to change its activity level. For a motherboard that’s on this doesn’t make too much of a difference, but apparently if the system is in suspended state (s2idle or deep) then this difference is measurable.
I bet it’s not as good as we might like!
always good for future users to have this context if they view your post in the future!