#9535 HIGH 10.1.3: need multicast group wakeups using the 8686 for wake-on-wlan vs collaboration
Zarro Boogs per Child
bugtracker at laptop.org
Mon Nov 15 17:32:49 EST 2010
#9535: need multicast group wakeups using the 8686 for wake-on-wlan vs
collaboration
------------------------------+---------------------------------------------
Reporter: cjb | Owner: dsaxena
Type: defect | Status: new
Priority: high | Milestone: 10.1.3
Component: kernel | Version: not specified
Resolution: | Keywords:
Next_action: design | Verified: 0
Deployment_affected: | Blockedby:
Blocking: |
------------------------------+---------------------------------------------
Comment(by martin.langhoff):
"how is this solution different from simply disabling power management?"
Simple!
If we just disable power mgmt (when Salut is in use), we are awake all the
time. Given that a laptop "alone under a tree" (ie: no AP in sight...)
auto-tunes to adhoc 1 (mimicking auto-tuning to mesh 1 in earlier
releases) and to Salut (as it won't find an XMPP server), then the most
common situation for a laptop has it fully awake and burning power, for no
good reason.
With the patch I propose, power mgmt stays on, and we save battery. In a
perfectly quiet RF environment, we save lots of battery. Same on a mostly
quiet network.
If we see mcast or ucast frames we wake up briefly -- this means that
presence announcements are received ok, and that if we are in a collab
session we stay in sync with other nodes. So the Salut-is-broken-with-
power-mgmt-on situation is avoided completely.
If the laptop is on a very busy infra or ad-hoc network, where other XOs
are sending mcast frames, we'll stay awake longer. If it's busy enough
with mcast frames, we'll stay awake all the time.
This gradual effect is a significant win: we save power in many/most
cases, and Salut doesn't break.
The only not-nice scenario is that a busy Salut collab session between A
and B will keep C, D and E awake. So multicast group wakeups _are_ still
the right fix. But my patch (with improvements as you've suggested) is the
best workaround so far, by a large margin.
--
Ticket URL: <http://dev.laptop.org/ticket/9535#comment:47>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list