Re: Power envelope (was Re: radio off guarantee?)
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 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 -- Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power envelope (was Re: radio off guarantee?)
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 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. The current firmware has not yet been optimized, and is consuming much more power than it should once that is done. And future wireless will also help. - Jim -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Power envelope (was Re: radio off guarantee?)
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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
