Power envelope (was Re: radio off guarantee?)

[Dan Williams]

On Tue, 2007-09-18 at 12:12 -0400, Mike C. Fletcher wrote:
> John Watlington wrote:
> >>> Suppose I'm someplace where I don't expect or want to do any mesh
> >>> networking.
> >>> 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 

The .3W number is applicable to _infrastructure_ mode with the Marvell
part, because the device (like most 802.11 devices) can go into
powersave poll mode when in a BSS.  In ad-hoc situations, of course,
there is no central controller buffering frames and sending out the TIM
and therefore you have to have your RX pieces powered on most of the
time to receive traffic from other stations, or you start missing frames
entirely.  You can't use the same powersave algorithms in a mesh (or
adhoc even) network as you can use in an infrastructure network.  Of
course everything in the world right now pretty much uses infrastructure
networks, and so the powersave algorithms are tuned for that.  But mesh
requires new powersave algorithms, or at least an implementation of
existing algorithms.  There's enough work getting the mesh implemented
and working well right now without throwing power algorithms into the
mix.

Dan

> 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 
> the night).
> > While it makes sense to turn off the wireless networking interface on  
> > developer
> > 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
>