Yes it sadly is.
I have a magentic USB C cable, when connected direct to a PD|PPS output the LED on in only comes on when a load is conneted, If I connect the other UBC C via a USB A adapter then the LED comes on whether or not there is a load.
It seems the USB A must have power going to it all the time, that the old USB 2 and 3 protocols, the USB C only provides power when there is a connection. Old versus new.
Still I can get over the 1W usage, it’s obscene.
Fair enough
Yeah that’s just insane (my understanding though is that it’s closer to 500mW but that’s still very high considering the overall power consumption at idle). I hope that’s fixable in firmware although it seems Framework are very unproductive in that department. A lot of the power draw issues, especially the ones that are surely quite clearly fixable like power draw during sleep have been ongoing and documented since launch and still isn’t fixed.
Yes in the graphs above the first shows over 1W the next just less than 500mW ???
I must check my USB A
The way I’ve interpreted the graphs is that there is an initial bump that brings it to ~1W but then it settles closer to ~500mW
Yes I didn’t pay enough attention, thanks for pointing that out 
Yeah I think it is the right default and like Nils said above you can either install or use the other expiations you need as dongles.
That’s right. I measure each type A to use ~0.4W and HDMI ~0.9W. Let’s see if 12th gen boards perform better.
I was finally running some idle power tests and figured, why not, I’ll give it a try to see how the power draw is with some modules. Basically on my 12th gen system, there’s basically no difference (within MoE).
Here’s powerstat results with 2 x USB-A + 2 x USB-C modules:
Summary:
System: 2.66 Watts on average with standard deviation 0.06
C-State Resident Count Latency
C10 99.970% 15236 230
C8 0.002% 80 200
C6 0.001% 69 170
C1E 0.022% 740 2
POLL 0.000% 3 0
C0 0.006%
Histogram (of 30 power measurements)
Range (Watts) Count
2.596 - 2.618 14 ########################################
2.619 - 2.641 2 #####
2.642 - 2.663 4 ###########
2.664 - 2.686 1 ##
2.687 - 2.709 4 ###########
2.710 - 2.731 1 ##
2.732 - 2.754 1 ##
2.755 - 2.777 0
2.778 - 2.799 2 #####
2.800 - 2.822 1 ##
With the 2 x USB-A modules removed
Summary:
System: 2.61 Watts on average with standard deviation 0.04
C-State Resident Count Latency
C10 99.954% 14675 230
C8 0.001% 33 200
C6 0.001% 47 170
C1E 0.011% 418 2
POLL 0.000% 2 0
C0 0.033%
Histogram (of 30 power measurements)
Range (Watts) Count
2.579 - 2.598 18 ########################################
2.599 - 2.618 4 ########
2.619 - 2.637 1 ##
2.638 - 2.657 3 ######
2.658 - 2.677 2 ####
2.678 - 2.697 0
2.698 - 2.717 1 ##
2.718 - 2.737 0
2.738 - 2.756 0
2.757 - 2.776 1 ##
And with no modules plugged in:
Summary:
System: 2.66 Watts on average with standard deviation 0.06
C-State Resident Count Latency
C10 99.770% 14228 230
C8 0.001% 49 200
C6 0.001% 49 170
C1E 0.045% 990 2
POLL 0.000% 2 0
C0 0.183%
Histogram (of 30 power measurements)
Range (Watts) Count
2.592 - 2.617 5 ##################
2.618 - 2.643 11 ########################################
2.644 - 2.669 7 #########################
2.670 - 2.694 0
2.695 - 2.720 3 ##########
2.721 - 2.746 1 ###
2.747 - 2.772 0
2.773 - 2.798 1 ###
2.799 - 2.824 0
2.825 - 2.849 2 #######
One additional note since I was just doing some testing on the MicroSD card reader module. It appears to raise idle power usage by 2W+ (!!!) on my Framework. powerstat and powertop seem to disagree on C-State residency, but powertop seems to be more likely to be correct (since it matches the increased power usage) in suggesting that C10 never gets reached when the MicroSD card reader expansion module is plugged in:
C2 (pc2) 16.7%
C3 (pc3) 7.8%
C6 (pc6) 1.4%
C7 (pc7) 0.0%
C8 (pc8) 67.3%
C9 (pc9) 0.0%
C10 (pc10) 0.0%
I think the answer to this question is that one should absolutely order 4 USB-C/A expansion modules if they care at all about maximizing battery life. Honestly, Framework probably needs to test and list the power consumption for each of the modules under idle and in suspend in Windows and Linux since they appear to behave pretty wildly different.
Damn, so it’s still an issue with 12th gen boards…
@lhl What distro are you on? How are you getting 2 watts on idle?!! I could only get mine down to 3.5W with tlp on Arch. Any tips for more optimization? Thanks!
Ha, don’t get too excited, <3W is just for idle testing (display brightness at 0, no wm). I’m actually not doing much special, also running Arch w/ tlp. The main differences will be not running additional crap, and display brightness.
I’ve been keeping notes that’s accrued into a pretty massive writeup (which I previously posted to the user reports thread). Here’s the section where I detail my idle battery numbers, which at 200 nits is right in line with your numbers.
And here’s a section on power consumption optimization options in Arch.
I suspect manually updating EPP and PL1 via RAPL is where you could eek out some tiny gains, but Framework’s laptop battery life is primarily limited by:
having a too small 55Wh battery - my old Ryzen 4800H laptop idles higher, but also runs for much longer since it has a 91Wh battery. This is where something like the Slimbook Executive 14 or Tuxedo InfinityBook Pro 14 Gen7, with a 99Wh battery just simply outclasses the Framework (and at the same 1.3kg weight too). Not much to do there except to wait for better battery chemistry or a bigger battery mod (maybe taking out the speakers would be easiest?).
Alder Lake P: while its max performance is great, it gets it by having even worse power efficiency than Tiger Lake (wah wah). Sure you get low idle power at C10, but even at C8, you’ve basically lost all of that, and even something that should be efficient, like hardware accelerated YouTube video playback (double checked with btop and intel_gpu_top) still raises my power consumption to >10W (that would translate to only about 5h (300min) of video playback?!)
To put this in perspective, Notebookcheck clocked the Ryzen 6800U Asus Zenbook S 13 UM5302 (which has a less efficient OLED display and a 67Wh battery) at 550min on their WiFi 1.3 test (they tested the Framework 12th gen at 447min, so only about 10% more efficient there, but the Zenbook also also gets a whopping 912m on their H.264 video playback test. Their Zenbook can playback video longer than my Framework can idle.
Sadly they don’t have full numbers for the Framework, but you can compare the Zenbook to other 1260P laptops. On an efficiency (Wh adjusted) basis, the 6800U Zenbook outperforms the 1260P Lenovo Yoga 9i by about 20% in the WiFi v1.3 test, and by about 35% in the H.264 test.
Based on initial reports, it looks like Ryzen 7000 (Phoenix Point) is further going to make big strides on efficiency (moving to TSMC N4, claiming 25% better PPW), while Intel 13th Gen (Raptor Lake) is staying on Intel 7 and probably won’t have significant improvements, eg, falling further behind. Here’s hoping Framework has been planning accordingly.
(I think in 2022 for a premium thin and light, 8h of light productivity (emails, typing, web browsing, etc) should be a minimum bar, and the Framework simply doesn’t get there.)
@lhl how to you get C10 states? On my i5-1240P with debian 11 kernel backports 5.18.0-0.deb11.3-amd64 kernel powerstat displays only C3:
Summary:
CPU: 0.81 Watts on average with standard deviation 0.16
Note: power read from RAPL domains: package-0, uncore, package-0, core, psys.
These readings do not cover all the hardware in this device.
C-State Resident Count Latency
C3_ACPI 98.579% 11518 1048
C2_ACPI 1.230% 4450 127
C1_ACPI 0.048% 985 1
POLL 0.000% 4 0
C0 0.144%
Does powertop or turbostat report the proper states?
If not, the only other thing I’d try out is to run a mainline kernel and see if it’s something Debian’s kernel is doing.
The processor supports C0, C2, C3, C6, C8, and C10 package states.
@lhl thanks for your reply.
powertop, powerstat and cpupower are all in agreement on the idle states (turbostat is not in debian repo AFAIK).
# cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyse du CPU 0 :
Number of idle states: 4
Available idle states: POLL C1_ACPI C2_ACPI C3_ACPI
POLL:
Flags/Description: CPUIDLE CORE POLL IDLE
Latency: 0
Usage: 14131
Duration: 2974257
C1_ACPI:
Flags/Description: ACPI FFH MWAIT 0x0
Latency: 1
Usage: 83986
Duration: 25827274
C2_ACPI:
Flags/Description: ACPI FFH MWAIT 0x21
Latency: 127
Usage: 104945
Duration: 142211325
C3_ACPI:
Flags/Description: ACPI FFH MWAIT 0x60
Latency: 1048
Usage: 98141
Duration: 4165073409
I tried the 5.18.0-4 from testing same result, but with 5.19 from experimental repo I get C10 :
# cpupower idle-info
CPUidle driver: intel_idle
CPUidle governor: menu
analyse du CPU 0 :
Number of idle states: 5
Available idle states: POLL C1E C6 C8 C10
POLL:
Flags/Description: CPUIDLE CORE POLL IDLE
Latency: 0
Usage: 4841
Duration: 901197
C1E:
Flags/Description: MWAIT 0x01
Latency: 2
Usage: 8648
Duration: 1620716
C6:
Flags/Description: MWAIT 0x20
Latency: 170
Usage: 321
Duration: 154874
C8:
Flags/Description: MWAIT 0x40
Latency: 200
Usage: 313
Duration: 205503
C10:
Flags/Description: MWAIT 0x60
Latency: 230
Usage: 5549
Duration: 23446705
# powerstat -cDHRf 2
Summary:
CPU: 3.54 Watts on average with standard deviation 2.59
Note: power read from RAPL domains: package-0, uncore, package-0, core, psys.
These readings do not cover all the hardware in this device.
C-State Resident Count Latency
C10 97.151% 56444 230
C8 0.092% 1181 200
C6 0.073% 1146 170
C1E 0.384% 8633 2
POLL 0.001% 36 0
C0 2.299%
Hello,
did you made any tests or found anything out about this?
Wanted to test it aswell, but I wasn’t even able to figure out which the P cores are, so I don’t know which I should disable
I think in the BIOS it has a setting for the number of active P cores and a separate one for the E cores. I tried 2 P cores and 4 E cores but my power usage didn’t decrease unfortunately which is a little annoying
Has anyone tested the power consumption of the DisplayPort expansion card?
Thing is, the HDMI expansion card is almost certainly an active adapter which, by its nature, means that it needs to draw power. DisplayPort however can be directly transmitted over USB-C without any conversion (hence the existence of bi-directional USB-C / DisplayPort cables), so it’s extremely possible that, like the type-C expansion cards, the DisplayPort expansion card could just be a “dumb passthrough” as well.
Not all power leakage is through power consumption by the card. The USB-A is dumb, but it also causes a noticeable increase in power usage by the laptop (even in idle). Apparently this is due to some connection that a USB-C-to-USB-A adaptor makes between certain pins of the USB-C that triggers the USB-C interface to do some discovery about possible PD requirements, and this then uses a noticeable amount of power. Since laptops with native USB-A ports don’t tend to have this problem with those, I guess it means that USB-A by itself can be wired in a way that doesn’t cause this draw.
I guess the USB-A card should really be a little less dumb and detect somehow if there is anything plugged in (through a mechanical switch maybe?) and then switch the connection on the USB-C side depending on that.
The expansion cards should really be marketed as well-fitting dongles.