Second, there's no proprietary battery magic in macOS, as stated in the article I already achieve 10.5W idle power consumption on my Ivy Bridge MacBook Pro with discrete GPU, Thunderbolt and AirPort suspended, wheras macOS achieves 7W. I've noticed a GPE in the ACPI tables for the Firewire controller which presumably signals hotplug when the controller is asleep. We're not using that on Linux yet, we keep the Firewire controller active all the time. Adding that would probably save another 1W.
So we're inching ever closer to macOS levels of battery life, and I think eventually we may be able to surpass it because of the sophisticated CPU pstate management that Intel developers continue to tweak with every new release.
I'm not knowledgeable enough, but this seems a pretty reasonable assumption for 90% of use cases. And if this assumption holds, is it fair to say. I think what you're trying to say is "First of all, macOS power manages devices too aggressively for me"
> It looks like macOS suspends the BCM 57765 Ethernet controller and doesn't resume it upon reception of packets from the LAN.
What are the trade-offs of this decision? Could apple not do this and not change the battery life for anyone? Or would it benefit this case and adversely affect other cases?
The case I was referring to was with the Ethernet cable still plugged in. They seem to suspend the Ethernet controller but don't wake it when packets come in, presumably because the controller doesn't support that. The machine appears dead from the outside after a few seconds of inactivity.
It seems like that would affect more than ssh connections, e.g. you wouldn't be able to receive email notifications.
Would these options help?