Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Power Wireless Networking

Controlling Wi-Fi Radio 'Nap-Time' Saves Power 43

alphadogg writes "A Duke University grad student has come up with a way to double (or more) battery life in Wi-Fi devices, without any changes needed on the device itself. Essentially, the technique regulates how long and when client radios sleep (PDF), so that data transfers can be scheduled more efficiently. In a test using eight laptops and nine Nexus One Android-based smartphones on an 802.11n network, the researchers found that the scheduling technique, dubbed SleepWell, resulted in energy reductions of 38% to 51% across a variety of online applications, including YouTube, Pandora and Last.fm Internet radio, and TCP bulk data transfers. What's more, they found that as the quality of radio links degrades, the relative energy gains are even higher."
This discussion has been archived. No new comments can be posted.

Controlling Wi-Fi Radio 'Nap-Time' Saves Power

Comments Filter:
  • by Anonymous Coward

    Doesn't PowerTOP already do this? What's new here?

  • 51% is double? Interesting math.

    • Re:double? (Score:5, Informative)

      by mwvdlee ( 775178 ) on Friday July 01, 2011 @05:38PM (#36637776) Homepage

      If it's a 51% reduction in power usage, then it would be about a 204% increase in battery life.
      I know it's not exactly double, but really, I think you're being a bit harsh here.

      • by Anonymous Coward

        actually, increase is 102%

      • Sorry to be pedantic, but battery lifetime would be 2.04 times the original value, or a 104% increase. When you double something, you increase it by 100%, not 200%.

      • Correcting a maths mistake with an English mistake. It's not a 204% increase in battery life, it's 204% of the total battery life. The increase is 104% since 100% means battery performed as it did originally.

        If you double something you get a 100% increase.

        • Correcting a maths mistake with an English mistake.

          ...on a Friday night before a major US holiday...

          100% chance nobody here will get an STD.

          • by Anonymous Coward

            Probably correct, OTOH some of us are married w/ trophy wives, so 100% chance of getting laid without STDs - we can spend as much time on /. as we want, holiday or not.

    • by robmv ( 855035 )

      if your phone use half of the battery power than before (50% reduction of power consumption) that means double battery life, the real problem here is not math, is that Wifi usage is not the only way to consume power, screen is a big factor, so half reduction on Wifi usage does not always means half total power usage, so that statement is only true when other parts of the phone are using much less that Wifi like screen being off

      • I almost never use wifi on my phone. Maybe once every few months, if that.

        • by Nethead ( 1563 )

          Well, I use it all the time for UMA at home. Not that I'm expecting BlackBerry to ever incorporate this code in my old Pearl.

          • For me, it's pretty rare that I'm someplace where I'll be using my phone for something that needs lots of bandwidth, but not be near a computer which I'd rather use, anyway. Different usage for different folks, though.

            • by cdrguru ( 88047 )

              Bandwidth? How about free calling? Unfortunately, T-Mobile dropped the UMA feature and free calling so you can't get it anymore unless you already have it. I wouldn't expect to see it as a feature on any phones any longer either. It was an obvious money-loser from the beginning.

              Of course being able to go from lots and lots of minutes a month to almost nothing certainly was handy. And reduced the bills a lot. Of course now you can just get an unlimited plan for about twice as much. Funny how that work

              • Like I said, different usage for different folks. I have 450 minutes/mo on my Sprint 'Everything 450' plan, and usually wind up using fewer than 20 (twenty). Even if I did talk a lot, it would be VERY hard for me to go anywhere near 450 since Sprint gives you unlimited anytime calling to any mobile number (regardless of carrier) in the U.S. I don't talk to anyone outside of the U.S., so for me, this is a super-moot point. But I can see where some people would find value in that.

                • by Nethead ( 1563 )

                  Not so much the free calling (I have unlimited because of my work) but for getting a signal at all. I live out on an Indian reservation where the T-Mobile signal is very weak. UMA lets me get calls at home when I'm not out on the deck.

                  Speaking of grandfathered, I do have the T-Mobile "POTS" line on my router. The router actually takes a SIM card and hands me a "POTS" line. $15/month unlimited. Too nice to give up.

      • On my Galaxy S, which uses a similar screen to the Nexus One used in this study, the screen consumes > 90% of all power. 3G, WiFi, GPS and everything else are just drops in the bucket.

  • AFAIK, using streaming services like Youtube, pandora and last.fm would require a constant connection to avoid stuttering and eventual disconnect. How can you use these services with the wifi radio in sleep mode?
    • Buffering. Constant doesn't have to mean actually constant: It just means the drop-outs need to be short enough that the buffer can handle them.
    • Re:enlighten me (Score:5, Informative)

      by TheRaven64 ( 641858 ) on Friday July 01, 2011 @06:52PM (#36638320) Journal
      I didn't RTFA, but it seemed to be talking about transmit not receive. Generally, transmitting takes a lot more power than receiving. At the TCP level, you need to send an acknowledgement for every group of packets that's been received. If you increase the window size, you send these less frequently. Rather than sending the acknowledgement every n packets, you'd send two acknowledgements every 2n packets. More importantly, if you are downloading over two TCP connections at once, then you can send the replies to both in the same transmit window, so the transmitter is active for a slightly longer time once, rather than a slightly shorter time twice.
      • by Anonymous Coward

        As someone who has worked on low power wifi chips I can categorically state that you generally burn much more power on receive than transmit. Sure, while it's transmitting the transmitter sucks more power than anything else. However the receiver draws a non trivial amount of power while it's just hanging around waiting for packets to appear on the medium. This is called wait to receive and it's generally the biggest power sync. The various sleep modes address this through a combination of negotiating period

        • A scheme that optimizes when the various attached clients come on the medium to collect there traffic could well have the power gains described.

          But, if you're not always listening to the medium, you're bound to miss some opportunity to receive data. The paper seems to say with some methods, the AP wakes the client, and then transfers to it, possibly queuing multiple packets before waking up the client. I'd expect there to be an increase in latency with a scheme like that, and indeed the article seems to me

          • by tlhIngan ( 30335 )

            But, if you're not always listening to the medium, you're bound to miss some opportunity to receive data. The paper seems to say with some methods, the AP wakes the client, and then transfers to it, possibly queuing multiple packets before waking up the client. I'd expect there to be an increase in latency with a scheme like that, and indeed the article seems to mention that. (But, for what one is doing on a mobile device, it probably won't matter.)

            You only miss data if you don't wake up in time. The AP per

    • Generally you have more bandwidth available than you need on average, so your client will buffer and then stop reading. I'd expect the WiFi connection to go into low power mode during those pauses.

  • Sounds a whole lot like "sniff mode" commonly used on (non-sucky implementations of) Bluetooth.

Remember to say hello to your bank teller.

Working...