Power envelope (was Re: radio off guarantee?)
Mike C. Fletcher
mcfletch at vrplumber.com
Tue Sep 18 12:12:56 EDT 2007
John Watlington wrote:
>>> Suppose I'm someplace where I don't expect or want to do any mesh
>>> How much would turning off the radio help battery life?
>> Last I checked, the effect was very small. There will be occasional
>> scans as the unit hunts around for nearby radios. One could save more
>> by making those scans back off rather than provide a UI element.
> We see 700 to 800 mW consumed by the mesh interface, and as with most
> WiFi interfaces, receiving consumes as much power as transmitting.
Isn't that about 1/2 of our total power budget? .7 to .8 W on a < 2W
machine? I'd thought the Marvell chip was supposed to be down in the
.3W range. Obviously haven't been following the hardware closely
enough. (http://wiki.laptop.org/go/Power_Management is where I got the
.3W idea). Is that .7W something we'll be able to bring down with
software to reduce collisions or the like? University of Toronto's
system's group has algorithms that optimise for power savings by
reducing collisions, if that would help.
From the same page, we'd only last 20 hours at ~.7W draw with a *full*
charge (and with hand-charging a full charge likely won't be there,
especially at the end of the day), which means that the machines are
going to be dead each morning (having drained their batteries keeping up
an unused network all night). With a 40 hour period (.3W) we were
possibly going to have some juice left in the morning (need to be at >
1/4 power when you shut off for the night), but that becomes less likely
with a 20 hour period (need to be at >1/2 power when you shut off for
> While it makes sense to turn off the wireless networking interface on
> machines, we are hesitant to add this to the UI. We are really
> relying on laptops
> to extend the mesh away from the school.
If we really are spending half our power budget on the mesh network I
would imagine that kids will want to be able to turn it off. Yes,
meshing is good, but if you could double your battery life while you're
at home reading, that would be very worthwhile too. What about *only*
keeping the mesh up (continuously) if you are actually routing packets?
That is, wake up the mesh interface every few minutes, check to see if
your new routing structure makes you a link that is desirable, and only
stay on if that's the case. (I realise I'm talking about long-term
projects here). You'd need the machines to be able to queue up messages
to go out so that they could leap at the request and say "yes, please
stay up" when a linking machine pops on to check for need (implying from
activity requests on the local machine would be likely be sufficient,
but a simple UI might be workable too). If the network is inactive for
X period, go into periodic sleep mode again to save energy.
Even if you had to wake up the processor for a few seconds to run the
code that decides whether to sleep, it's only about double the power of
running the mesh for those seconds, and it could save you the entire
power budget for a few minutes. Of course, in the field it may be that
the mesh is so densely used that it's never going to go down with that
algorithm, but it seems like something we need to investigate if we
really are losing that much power to the interface.
Just a thought,
Mike C. Fletcher
Designer, VR Plumber, Coder
More information about the Devel