CPU Power consumption

[velaar]

@tylernguyen Can you please confirm the CPU power of about 2W on PKG when idle? If possible also post an Intel power gadget screenshot.

I've got a feeling that the CPU power vectors are not exactly correct. I have a way lower PKG on Linux/Windows (<1W) and trying to pinpoint the issue.

Thanks!

[tylernguyen]

@benbender If you patch framebuffer-conX using alldata regressions, hardware flag bytes is matched to the ioreg dump of which platform and their respective graphics. That's a big problem in getting HDMI to work. The worse headache is the thunderbolt problems, each different platform has it own USB specifications due to the number of Thunderbolt ports it has, which is more headache when it comes to patching displayport and USB for thunderbolt.

Regardless, when I have time, I will do an extended testing of MacbookPro15,2 and get back to this issue. Thank you again so much for contributing @benbender

[benbender]

Hm, to be honest, I don't think so.

Alldata isn't matched to anything, but a concatenated string of all the connector variables you could define independently. It doesn't make any difference other than its more error-prone and less readable (at least for me).

Its (if I remember correctly) simply: Index-BusId-Pipe-ConnectorType-FramebufferFlags concatenated.

USB/TB-Ports rely on the names originating from acpi. So I don't know about any relevance of the platform-id.

[benbender]

Oh, I might have misunderstood: if you don't define every variable its "matched" against the defaults of the framebuffer, yes.

But those are, at least to my knowledge not related to the platform-id in hackintosh-land. You could, technically, have a haswell-framebuffer-kext loaded on icy lake.

[tylernguyen]

Oh, I might have misunderstood: if you don't define every variable its "matched" against the defaults of the framebuffer, yes.

But those are, at least to my knowledge not related to the platform-id in hackintosh-land. You could, technically, have a haswell-framebuffer-kext loaded on icy lake.

I think you are right. Though the thought of doing that makes me uncomfortable somehow. But again, I think you're correct that it should not matter. So I guess after all, I should change my SMBIOS and test performance/power between the two.

Though I do not know how to do this objectively. Do you have any ideas on how to compare the two SMBIOS's performance and pwoer fairly?

[benbender]

Not really. If you are willing to invest the time, you should try to find a comparable scenario which is repeatable.

f.e. boot, wait 2 min for the os/cpu to settle and run geekbench, compare max power-usage.

And that should be done with one change at a time. But even than there are more factors like temperature which will interfere. If the difference isn't directly noteable, it will be hard. And I don't think there are big, easy gains - if there were, they would be known.

On the other hand, most of the hackintosh-folks just repeat what is there in terms of knowledge/experience - and these are often outdated, undercomplex or simply false.

F.e. weg with -wegnoegpu simply shuts down the pcie-port of the egpu. I've had the feeling that it makes a difference to shut down optimus properly. But I didn't do any real meassurements to back up my feeling ;)

[benbender]

btw as an example of "outdated" knowledge: for me, sleep/hibernate is working perfectly fine with only one line of acpi-patch, darkwake=4 and womp and proximity-alert disabled (which may activate bt/glan in sleep and not supported anyways). besides of these things, my pmset-configs are untouched and fine (for me), even with darkwake enabled.

no name6d/gprw-patches or such needed. Those are, if needed at all, highly hardware specific patches.

But you have to acknowledge that some functions of osx are firmware-dependent and simply not available to us (f.e. wakeup by BT-mouse, which would us force to power up the usb-bt-adapter, which would lead to battery drain in sleep... etc)

[tylernguyen]

btw as an example of "outdated" knowledge: for me, sleep/hibernate is working perfectly fine with only one line of acpi-patch, darkwake=4 and womp and proximity-alert disabled (which may activate bt/glan in sleep and not supported anyways). besides of these things, my pmset-configs are untouched and fine (for me), even with darkwake enabled.

no name6d/gprw-patches or such needed. Those are, if needed at all, highly hardware specific patches.

But you have to acknowledge that some functions of osx are firmware-dependent and simply not available to us (f.e. wakeup by BT-mouse, which would us force to power up the usb-bt-adapter, which would lead to battery drain in sleep... etc)

I've been experimenting with hibernation but I'm always hit with a CMOS error when I try to hibernate on mode 25. Were you able to get true hibernation to work?

[benbender]

I didn't try mode 25. Default on modern macs is 3 (mixed ram-sleep/hibernation to disk) and working perfectly fine for me. I can sleep my notebook over night without any battery drain and with attached usb-devices (which suck battery on an always-on-usb-port... ^^). That were my testcases.

Though I didn't test it for serveral days in sleep in case of drain. But that scenario doesn't matter to me anyway - I do need my notebook too often ;)

[tylernguyen]

I didn't try mode 25. Default on modern macs is 3 (mixed ram-sleep/hibernation to disk) and working perfectly fine for me. I can sleep my notebook over night without any battery drain and with attached usb-devices (which suck battery on an always-on-usb-port... ^^). That were my testcases.

Though I didn't test it for serveral days in sleep in case of drain. But that scenario doesn't matter to me anyway - I do need my notebook too often ;)

Yeah, mode 3 has been working perfect for me as well. Though mode 25 is what I'm really after. And as far as I know, most hackintosh projects do not have trouble with mode 3 after some small macOS tweaks.

[benbender]

May I ask why? Is there any benefit besides of "I've done it!"

[tylernguyen]

Mode 3 seems to be draining a decent amount of power for me, more than it does compared to S3 sleep on Windows or Linux anyway. So I wanted to get mode 25 working to see how much power it drains.

Though I suppose I should patch USB via ACPI to see if that improves anything.

[benbender]

I can sleep mine in mode 3 for 8 hours, "pmset -g log" is nearly empty between sleep and wake and no visible drain at all.

For reference:

❯ pmset -g
System-wide power settings:
 DestroyFVKeyOnStandby      1
Currently in use:
 standbydelaylow      10800
 standby              1
 womp                 0
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 proximitywake        0
 powernap             1
 gpuswitch            0
 networkoversleep     0
 disksleep            10
 standbydelayhigh     86400
 sleep                1
 hibernatemode        3
 ttyskeepawake        1
 displaysleep         10
 tcpkeepalive         1
 highstandbythreshold 50
 lidwake              1

Oh, and have a look at the GPE-Patch in SSDT-cpupm and in SSDT-DeepSleep - they may be a factor.

And with this, I have to leave ;)

[benbender]

On my way to bed: another difference might be that I didn't "disable" my sleepimage. So your system may stay in hibernate-to-ram and may not be able to go to hibernate-to-disk. That could mean that your ram is powered on the whole time and would, at least, attribute to the battery drain.

[benbender]

And a last last one:

a) here we might have another difference between platform-ids - you could compare your pm-caps in 14,1 with mine:

❯  pmset -g cap
Capabilities for AC Power:
 displaysleep
 disksleep
 sleep
 womp
 lidwake
 halfdim
 gpuswitch
 standby
 standbydelayhigh
 standbydelaylow
 highstandbythreshold
 powernap
 ttyskeepawake
 hibernatemode
 hibernatefile
 tcpkeepalive
 proximitywake

And there seem to be some reports of problems with hibernatemode 25 on genuine macs with catalina also. So there might be general bugs beside of the beloved hackintosh.

[velaar]

@benbender Right, but the problem is that a lot of our config.plist variables depend on Kaby Lake properties, not Coffee Lake ones. For examples, your device-id is 1659000 (Intel HD Graphics 620) while your AAPL,ig-platform-id is 05001C59 (Intel HD Graphics 630), both of which are Kaby Lake graphics. So when it comes to switching a different SMBIOS, it's a lot more work than just changing MacbookPro14,1 to MacbookPro15,2. For it be to truly optimized and improve anything, you would need to patch various variables to be in sync with your SMBIOS. Or at least that's what I'm assuming? it not even affect anything if the SMBIOS definition and various config variables do not match

This chain got a little bit lost with hibernation-related messages. The question for this issue at the moment is should we move the repo to 15,2 SMBIOS? If yes, is it worth the hassle with iMessage/FT/AAPL integration.

The power consumption is still an issue and the best of my knowledge it is not as much about CPU/Graphics but Thunderbolt/USB3.2 power management (that causes the C-states to go up)

[tylernguyen]

@velaar @benbender There also exists more options: MacbookAir8,1 with its graphics injection of the UHD617 may be kinder on CPU power consumption as well. Also remember that changing SMBIOS will also mean that we need to generate a new USBPort patch each platform (which should be easy).

Again, I want to test this in a fair way. But I don't really know how the best method to compare SMBIOS performance and power consumption.

[benbender]

Hey,

@velaar For me, CPU-performance and power-consumption is quite good with 15,2 without any real hassle. It's not that much of a pain to change, but I tend to think It doesn't matter that much.

Could you give me a pointer how to diagnose the power-management/c-states problem? I know that there was a bug in the TB-FW on many Thinkpads in 2018, but it's fixed afaik.

@tylernguyen I didn't consider MacbookAir8,1 at all before, but I don't think, I will investigate in that direction any time soon.

I tested a configuration a few days back where I pushed CPU/GPU to be coffee-lake (lilucpu=10, whatevergreen). It did run without any big trouble (besides different PNLF-Registers, so backlight-controls didn't work without patching), but I didn't saw much of a difference. So I'm tending to believe that that the plattform-id might be a minor factor of PM.

As I said, I will most likely give up testing in that direction and concentrate on PCI-E/USB as my CPU-Stats are looking OK to me (but not "perfect"). I think that usb-suspense of the webcam/cardreader are a real-problem and the thunderbolt-controller is still an issue too.

BTW, I had a look on an macbook-pro15,1 ioreg and ASPM was only activated on WIFI and NVME. So I assume, that's OK.

my basic problem with power management atm is, that, from my knowledge, there is no tool like powertop on linux to really meassure power consumption of the hardware (mainly pcie/usb-devices) on OSX. Without that, we are kinda blind on testing. In my opinion the focus on CPU-Watts might be a bit false leading, when things like the cardreader are eating 500mW constantly and we don't have a good way of debug those problems.

[07151129]

my basic problem with power management atm is, that, from my knowledge, there is no tool like powertop on linux to really meassure power consumption of the hardware (mainly pcie/usb-devices) on OSX.

It does have powermetrics.

[benbender]

@07151129 yes, it does. But f.e. I don't know of any way to debug the real power consumption of an internal USB-device (like an USB-cardreader). It's shows mainly Interrupts and C-States afaik - Or am I missing something?

[07151129]

It is capable of computing device power state residency, which closely correlates with the energy consumption by a device. In theory, those numbers can be translated to Joules, but very few drivers publish power consumption metrics. It still useful if you want to ensure that your device goes to low-power states when expected.

[benbender]

That sounds interesting. May I ask if you have any links to read further? I didn't found any possibility to debug power-usage of f.e. USB-Devices, just processes, GPU/CPU and ACPI-Devices.

My actual thought was like this: we can debug power-usage of the CPU. Its between 1-3W for the 8650u in idle. The machine is using 10-15W with low load. There are many other power-drawing sources in the machine for which we don't know of any possibility to debug on OSX. That's the reasoning for my statement about the missing debug-capabilities. Especially on the X1C6/T480 there might be a constant power-draw by the TB-Controller and the Webcam/Card-Reader which I suspect to be part of the reason for the worse battery-performance compared to Windows - which I'd like to tackle.

Btw: Thanks for your work and help! Much appreciated!

[07151129]

Have you tried powermetrics --samplers devices? It shows state residency per device class. This should be traceable back to the actual device IOReg path, but it looks like the program won't do that.

[benbender]

Yes, but didn't seem to be helpful to me:

❯ sudo powermetrics --samplers devices
Password:
Machine model: MacBookPro15,2
SMC version: Unknown
EFI version: 1517.0.0.115.1
OS version: 19F101
Boot arguments: debug=0x100 keepsyms=1 -disablegfxfirmware
Boot time: Tue Jun 30 17:47:43 2020

*** Sampled system activity (Tue Jun 30 18:18:46 2020 +0200) (5002.11ms elapsed) ***

**** Device Power States ****
Device                              State Residencies ms/s
IOPMrootDomain                         0.00     0.00     0.00     0.00  1000.00O
ApplePS2Controller                     0.00     0.00U 1000.00U
AppleACPIPCI                           0.00     0.00  1000.00O    0.00
AppleIntelFramebuffer                  0.00     0.00  1000.00U
AppleIntelFramebuffer                  0.00     0.00  1000.00U
AppleIntelFramebuffer                  0.00     0.00  1000.00U
AppleBacklightDisplay                  0.00     0.00     0.00U 1000.00U
AppleIntelFramebuffer                  0.00     0.00  1000.00U
AppleIntelFramebuffer                  0.00     0.00  1000.00U
AppleIntelFramebuffer                  0.00     0.00  1000.00U
AppleIntelFramebuffer                  0.00     0.00  1000.00U
AppleIntelFramebuffer                  0.00     0.00  1000.00U
AppleIntelFramebuffer                  0.00     0.00  1000.00U
IOUSBMassStorageInterfaceNub           0.00  1000.00U
BroadcomBluetoothHostControllerUSBT 1000.00     0.00L    0.00U
...

[tylernguyen]

Btw, an interesting project to keep and eye on: https://github.com/syscl/CPUTune

[benbender]

Another one (based on VoltageShift): https://github.com/tctien342/smart-cpu

[thalatamsainath]

So I have had great CPU power usage and total discharge on i7-8550U in Asus Zenbook S. With thunderbolt(turned on) its 1.7W and without thunderbolt(post sleep - sleep breaks thunderbolt) around 1W(goes lower(0.65W) with wifi and bt turned off).

Attached are with thunderbolt (broken post sleep).

[benbender]

The 4 Watt overall usage are impressive - mine is around 6 or more :)

May I ask some questions:

• Why do you do combine your dsdt-hotpatches?
• Did you notice any difference with macbookpro16,3-plattform?
• How did you generate your CPUFriendProvider.kext? (afaik most tools doesn't support macbookpro16,x yet)
• What are the AppleRTC-patches for?

[thalatamsainath]

1) I used to use separate Hotpatches but I could never get battery indicator to work. When I contacted the folks at olarila for help they managed to get my battery indicator working but they use only full DSDT patching. never took the time out to create hot patches from it. 2) Honestly 16,3 has been more stable for me than 14,1 and 15,4 or 15,2 as well. 3) I used ResourceConverter.sh and edited Mac-E7203C0F68AA0004.plist (had to go through some old documentation fo edit the frequency vector). 4) They are useless. I have been trying to fix few Sleep/Wake issues causes by RTC wake ups so was testing something.

[benbender]

First, thanks for your response! I just realized that the discharge value seems to be sampled over time and doesn't seem to give a live-value. You left your system to idle quite some time to reach that point, right?

When I let my T480 idle for around 10 minutes, I also can reach about 4-5Watt.

Another factor seems to be hidpi, if I go down to 1280x720 instead of 1920x1080 (hidpi), the power usage seems to be dropping a bit.

[thalatamsainath]

Lol. See ofc if you are working on laptop its going to consume more power. For me its reaches upto 6W on web surfing and higher depending on the task.

From the thread I can see most of discussion are about idle power consumption. You can not compare power usage under load.

I can do 10 other things to reduce power consumption lower than even that 4W but the screenshot is on a useable idle system(50% Brightness, Wifi and Bluetooth are on and connected, apps running in background, 1080p 60 fps resolution). I left the system to idle for 1 min and took a screenshot.

[benbender]

Sure, that's what I meant: mine needs ~5-10 minutes to reach that state and not after letting it idle for 1 or 2 minutes. That's what I was wondering about.

[thalatamsainath]

Sure, that's what I meant: mine needs ~5-10 minutes to reach that state and not after letting it idle for 1 or 2 minutes. That's what I was wondering about.

No no. I meant I let it sit for 1 min to cover the full 60 sec graph of the intel widget. But the power usage drops to 0.8W the second I just leave the laptop to idle and that's how it should be. Check for apps that aren't idling in your usage. There are no apps to find instant power draw other than Intel Widget so I'm assuming the sec Total pkg drops to 0.7W the total draw also drops to under 4W.

[benbender]

I was talking about the "discharging with"-value in coconut-battery in your screenshot. It originates from "AppleSmartBattery"-node in ioreg. That value reflects the discharge-rate of the battery and should therefore include things like display, usb, etc. Tuning of the CPU is only one part of the puzzle.

[tylernguyen]

Did some light testing of MacbookAir8,1 including matching framebuffer, usb remapping, cpufrienddataprovider As far as I can tell, there was not much a different in power consumption or performance. This is after 2 days of normal usage and some light benchmarking with GeekBench and Cinebench.

So it seems that changing the SMBIOS will be a very minor if even effective part of dealing with power consumption. I will suggest looking into other aspects instead.

[benbender]

Yes and no. Did you regenerate CPUFriendProvider.kext with the changed Plattform-Id? Info.plist of the board is used as base to patch frequency-scaling etc. If you didn't, there wont be really that much visible difference.

The real difference between plattforms are the values in the plists of the boards. To see what differs, have a direct look at: /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/.

But I'm +1 in the sense that this isn't the main point of tuning.

[tylernguyen]

Yes and no. Did you regenerate CPUFriendProvider.kext with the changed Plattform-Id? Info.plist of the board is used as base to patch frequency-scaling etc. If you didn't, there wont be really that much visible difference.

The real difference between plattforms are the values in the plists of the boards. To see what differs, have a direct look at: /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/X86PlatformPlugin.kext/Contents/Resources/.

But I'm +1 in the sense that this isn't the main point of tuning.

@benbender as stated above, I did. Also redid usbmapping since it the kext it generates matches the platform, and I also included matching framebuffer in testing so I am sure now that SMBIOS does not have any significant power consumption effect.

[benbender]

After some more research: The Answer to the implications of the plattform-id is not clear because there are many (small) moving parts to the equation and the implications changed over time and with the usage of HWP on modern Intel CPUs.

• The powermanagement of the gpu(s) IS depending on the choice of the plattform. The values of our GPU-PM can be seen under "AGPMController" and "AppleGraphicsDevicePolicy" in ioreg. The latter seems to be more important with configurations with a working dGPU.

• In the past there WAS a significant involvement of the plattform-id in cpu-scaling and thermal management, but that can be completely altered nowadays by CPUFriend/one-key-cpufriend (which injects essentially only parameters to X86PlatformPlugin and can be viewed in ioreg). BUT most of the tools to generate CPUFriendProvider.kext or similar are depending on the plattform-choice. The direct powerconsumption should be less effected, but it is over time because of different scaling-profiles/optimizations between different plattforms.

• There could be more, but I couldn't find other references by scanning original macbook's ioreg.

Additionally there are many small parts and apps which are using the plattform-id to manage assumptions about the hw. F.e. naming of sensors in iStat.

So, in conclusion, I'll heading back to a macbookpro14,2-configuration with a CPUFriendProvider.kext generated on macbookpro15,2 and I will try to patch my system to be as closely as possible to match the macbookpro14,2-config.

[zombillano]

After some more research: The Answer to the implications of the plattform-id is not clear because there are many (small) moving parts to the equation and the implications changed over time and with the usage of HWP on modern Intel CPUs.

* The powermanagement of the gpu(s) **IS** depending on the choice of the plattform. The values of our GPU-PM can be seen under "AGPMController" and "AppleGraphicsDevicePolicy" in ioreg. The latter seems to be more important with configurations with a working dGPU.

* In the past there **WAS** a significant involvement of the plattform-id in cpu-scaling and thermal management, but that can be completely altered nowadays by CPUFriend/one-key-cpufriend (which injects essentially only parameters to X86PlatformPlugin and can be viewed in ioreg). **BUT** most of the tools to generate CPUFriendProvider.kext or similar are depending on the plattform-choice. The direct powerconsumption should be less effected, but it is over time because of different scaling-profiles/optimizations between different plattforms.

* There could be more, but I couldn't find other references by scanning original macbook's ioreg.

Additionally there are many small parts and apps which are using the plattform-id to manage assumptions about the hw. F.e. naming of sensors in iStat.

So, in conclusion, I'll heading back to a macbookpro14,2-configuration with a CPUFriendProvider.kext generated on macbookpro15,2 and I will try to patch my system to be as closely as possible to match the macbookpro14,2-config.

T480 owner here. I would like to offer my help at testing (if you need it, of course). I have the one that comes with i7-8650u without dGPU and power management is one of the topics i've been looking every now and then (I've only got focussed on solving a problem that I'm having with my SSD). Hope I can help.

[velaar]

CPUFriendProvider.kext generated on macbookpro15,2

@benbender can you please share the kext? I'd like to do some testing.

[benbender]

@velaar Just take the one from the zip here: https://github.com/tylernguyen/x1c6-hackintosh/issues/28#issuecomment-649120727

[tylernguyen]

An update on the issue, I confirmed that there's a BIOS mod working on the x1c6, see Issue #68 I assume that the unlocked BIOS will give us more options to control power usage/consumption on the machine. I just finished the mod today so I am still exploring the advance menu. But give it a shot and look around.

These are the interesting unlocked options I'm looking at:

ACPI Settings:

• Native ASPM Enabling it allow for OS controlled ASPM, not sure if it works with macOS just yet.

[zombillano]

Does this open the door to CFG Unlock? I read somewhere that it is needed by macOS for proper power managment

[benbender]

@tylernguyen I don't think that it will improve much. Aspm is only enabled for NVME + WIFI on genuin macs. Confirmed in ioreg available here: https://github.com/khronokernel/DarwinDumped/blob/master/MacBookPro/MacBookPro14%2C1/

@zombillano Basically yes. But there are far more options around that topic and it is unclear (at least to me) what os x really expects.

[tylernguyen]

Confirmed that the modded BIOS's undervolt menu/options are working. This is particular great because macOS doesn't really have any nice tools for doing so right now.

My machine seems to be stable around -95 mV, not the world's best but I'll take it. Stress tested with Prime95 for 10 minutes.

Edit: another useful option is TDP Boot Mode, per this useful article: https://medium.com/@n4ru/45w-performance-from-15w-kaby-lake-r-d8d5e7ea4fad

• If you want a big boost in battery life in exchange for non-boost clocks being lowered to 800MHz, enable TDP Boot Mode and change the value to Down. Likewise, setting the TDP Boot Mode to Up will up the power limit to 25W and set the non-boost ratio to 2.1GHz, and 25W should sustain the full 3.9GHz boost on most medium loads.

[zombillano]

Wasn't voltageshift working for you? Either way, I believe that BIOS undervolting is a better aproach. I already ordered a CH431A programmer and will try to mod my BIOS as soon as it arrives.

[tylernguyen]

Wasn't voltageshift working for you? Either way, I believe that BIOS undervolting is a better aproach. I already ordered a CH431A programmer and will try to mod my BIOS as soon as it arrives.

I tried it and got it to a semi-working state but it has a lot of issues, particularly with the kext and sleep. And yeah, BIOS undervolting is just much better anyway. I'll rather use less kexts and software if I can.

[zombillano]

I saw the medium article that you posted. Then I found who wrote it, the good n4ru :D I will link you to this post at reddit about unlocking the TDP on a T480: https://www.reddit.com/r/thinkpad/comments/g8fk51/t480_consuming_60w_85w_total_unlimited_tdp/

45W TDP is insane, but it would be interesting to see if we can get sustained 3.9GHz even on high loads with something like 30W TDP or so. T480 benefits of being able to mod with dual heatpipe on the models without dGPU, which I believe gives the oportunity to the T480 to really squeeze out all the performance from the i7-8650u. I happen to have that exact model, so I will certainly give it a try soon. How are the thermals on the X1C6?

[tylernguyen]

I saw the medium article that you posted. Then I found who wrote it, the good n4ru :D I will link you to this post at reddit about unlocking the TDP on a T480: https://www.reddit.com/r/thinkpad/comments/g8fk51/t480_consuming_60w_85w_total_unlimited_tdp/

45W TDP is insane, but it would be interesting to see if we can get sustained 3.9GHz even on high loads with something like 30W TDP or so. T480 benefits of being able to mod with dual heatpipe on the models without dGPU, which I believe gives the oportunity to the T480 to really squeeze out all the performance from the i7-8650u. I happen to have that exact model, so I will certainly give it a try soon. How are the thermals on the X1C6?

I think thermals are fairly limited on the X1C6. The machine is pretty stuck with cooling it's got. There some remedies to be done:

• If you have the Furukawa/Nidec fan, you should replace it with a Delta one: https://www.reddit.com/r/thinkpad/comments/c7zpah/x1_carbon_6th_gen_horrible_cooling_fan_design/
• Repaste the machine with a better compound or liquid metal.

I've done the two things above and honestly, the machine still gets pretty warm on load. But, right now I'm trying to reduce power consumption on battery. Increasing power consumption on connected power for better performance is another issue for another day.

[tylernguyen]

With some advanced BIOS tweaking, I was able to get idle power consumption pretty low, pretty much identical to Linux/Windows.

All that's left is to experiment and play around with real world usage on battery.

[parndt]

@tylernguyen that's great news; can you please share your current BIOS settings?