Impacts of disabling Automatic Power Management
gnu at toad.com
Sat Feb 11 17:22:04 EST 2012
> The first problem I see is that machines don't wake on ARP.
> Ultimately I believe we don't want our machines to wake on ARP, we
> really want firmware that can handle ARP and only wake when our
> address is ARP'd. I don't know how unreasonable a request that is.
It's completely reasonable, and we've put together most or all of the
parts to get it working for IPv4. See:
If we fix the wake-on-multicast problem then we'll fix IPv6 ARP as
well (it uses multicast for "neighbor discovery" packets that replace
the ARP protocol):
> Another problem appears to be lost wakup packets while collaborating.
> This should be able to be fixed by using an iptables queue. If we
> queue collaboration traffic that isn't responded to, we can quick of a
> script when the queue gets X long that tries various methods to wakeup
> the machine on the other end.
We should fix the real problems, which are low-level, straightforward,
and easy to reproduce, rather than building crazy workarounds at
> Be smarter about how we track network traffic. Other than just
> checking if there is network traffic, we should be tracking where this
> network traffic is from or to.
We shouldn't need to check whether there is network traffic when
desiring to suspend. If no process has run in N milliseconds, the
kernel should autosuspend. N should be tuned to avoid constantly
suspending and then immediately reawakening, e.g. between packets in
an active HTTP connection.
More information about the Devel