Impacts of disabling Automatic Power Management

[Jon Nettleton]

On Sat, Feb 11, 2012 at 6:24 AM, Daniel Drake <dsd at laptop.org> wrote:
> On Thu, Feb 9, 2012 at 7:33 PM, Sridhar Dhanapalan
> <sridhar at laptop.org.au> wrote:
>>> Looking for the happy middle ground that doesn't interfere with
>>> collaboration.
>>
>> Emphasis on collaboration stability, but we would prefer not to have
>> massive battery drain while doing so. We understand that there are
>> trade-offs.
>
> I think its hard to find a middle ground at the moment. Maybe it is
> just subjective. As John Gilmore points out, we have years of
> experience of applying workarounds and it hasn't brought brilliant
> results. Recent workarounds have already shifted us quite
> significantly to the stability side (sacrificing power savings) -
> waking up on all multicast frames, apparently even ones that wouldn't
> normally be sent from the hardware to the driver - but we are still
> left with a (IMO) substandard experience for the field.
>
> If you apply the collaboration workaround in question you just shift
> the problem to other areas, such as presence and web browsing.
>
> In terms of the real solution, we are making progress on some of the
> issues. Slowly but surely.
>

I have never really been involved in collaboration and am just getting
up to speed but here are my observations as a fresh mind.

Right now almost all the collaboration problems seem to exist on the
client side of things.  That makes a lot of sense to me as the we know
there are limitations in the firmware we use for the wireless cards.
The way we work around that is disabling powersavings so the card can
"behave" normally.

My suggestion is that we can make the machines/servers acting as host
smarter and that can allow the best of both worlds.  This will
probably require reciprocal work on the clients but that will be
worked out in the development process.

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.
Without that option the next best thing is to have the other machines
on our network create a static ARP entry for other machines involved
in collaboration.  This makes it very easy for accurate unicast
wakeups.

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.

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.  The most recent solution I have seen
inhibits powerd if a collaboration session is invoked.  I think a more
fine grained hammer would be to register who is being colaborated with
and specifically watching for network traffic with those hosts.

I am most certainly missing some things, but I am quite sure that we
can make all this work by stretching the rules of modern networking a
bit.  More and more networking code is written with the assumption the
other machine is always online and accessible.  That is generally a
fair assumption, except in our model.  To get around this we will need
to make our networking model a bit more stateful, and intelligent.  I
think all the pieces exist we just need to pull it all together with
some duct tape and bubble gum McGuyver style.

Jon