Comment by l1k | Hacker News Reader

Comment by l1k | Hacker News Reader

Parent Full thread

First of all, macOS power manages devices too aggressively: I've noticed that if I ssh from another computer into my MacBook Pro (booted into macOS and connected to wired Ethernet), the connection becomes unresponsive after a few seconds of inactivity. I have to ping from the MacBook Pro to a machine on the LAN to make the ssh connection responsive again. It looks like macOS suspends the BCM 57765 Ethernet controller and doesn't resume it upon reception of packets from the LAN. Apple seems to consider macOS purely a client OS from which one ssh's to the outside world but not the other way round.

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.

> Apple seems to consider macOS purely a client OS from which one ssh's to the outside world but not the other way round.

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?

For a Linux driver it wouldn't be acceptable to compromise functionality like this as it's expected to work equally well on big iron as on laptops. So we have to tweak a lot more to achieve the same level of battery life.

Just to understand this, why wouldn't that be an acceptable compromise? As someone who uses linux on both a server and a laptop, I can tell you that when my laptop is unplugged, I'd much rather have that battery life than inbound ssh connection stability. I would imagine this is much the same for the vast majority of linux users. Could the lack of compromise be part of the problem?

If nothing's plugged in then many devices can indeed be suspended in some way, either by putting them in PCI power state D3hot or by cutting power if the platform supports it. Plug events are then signaled e.g. by an ACPI GPE (general purpose event, an interrupt sent by the platform to the OS).

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.

> 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.

Thank you for clarifying the case.

http://unix.stackexchange.com/questions/3026/what-options-se...

Would these options help?

Reply on news.ycombinator.com