Impacts of disabling Automatic Power Management

[John Gilmore]

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

  http://dev.laptop.org/ticket/3732

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):

  http://dev.laptop.org/ticket/4616

> Another problem appears to be lost wakup packets while collaborating.

  http://dev.laptop.org/ticket/6528

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

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

	John