Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

Soulskill posted about 3 years ago | from the excessive-nap-times-do-cause-problems dept.

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."

cancel ×

43 comments

Cool (0)

Anonymous Coward | about 3 years ago | (#36637544)

So when's this going to be added to the kernel, eh?

Re:Cool (0)

Anonymous Coward | about 3 years ago | (#36637656)

When every last goatse [goatse.fr] mirror is removed from the Internet.

PowerTop (1)

Anonymous Coward | about 3 years ago | (#36637576)

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

Re:PowerTop (0)

Anonymous Coward | about 3 years ago | (#36684544)

Um, no. Powetop is totally different.

Common sense (0, Insightful)

Anonymous Coward | about 3 years ago | (#36637626)

It's a wonder no one's done this already. Obviously Wi-Fi radios don't need to be on the entire time, especially in spectrum-crowded environments. Though I imagine this research was done because smartphones with Wi-Fi support have atrocious battery life when the feature is enabled.

Re:Common sense (5, Funny)

Hal_Porter (817932) | about 3 years ago | (#36637678)

Smartphones have batteries? My phone has at best a UPS feature as I walk from USB connection to car charger to AC adapter.

It's still pretty useful though.

Re:Common sense (1)

lc_overlord (563906) | about 3 years ago | (#36637942)

You can sort of already do this on android, just set the wifi to shut down when the screen is off.
Before i did it it my SGS could just about manage a day, now it's at least 3 maybe 4 if i don't play any games on it.

Re:Common sense (1)

asdf7890 (1518587) | about 3 years ago | (#36640380)

Even with WiFi, bluetooth and GPS off all the time my Motorola thingy can barely do more than 36 hours standby time.

Overall, not much power saving (0)

Anonymous Coward | about 3 years ago | (#36637698)

That's great, but the two largest power drains in my Nexus One are (in order of power consumption):

a) The display
b) GPS receiver

WiFi is a drop in the bucket for my usage patterns, comparatively speaking.

double? (0)

Tumbleweed (3706) | about 3 years ago | (#36637726)

51% is double? Interesting math.

Re:double? (0)

Anonymous Coward | about 3 years ago | (#36637768)

You're joking, right? 51% *reduction* in energy use (i.e. cut energy use in half) --> double battery life. You find this math interesting?

Re:double? (0)

Anonymous Coward | about 3 years ago | (#36639072)

50% reduction in wifi energy use (where wifi energy use comprises a small percentage of total energy use) != double battery life.

Re:double? (4, Informative)

mwvdlee (775178) | about 3 years ago | (#36637776)

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.

Re:double? (1)

Anonymous Coward | about 3 years ago | (#36637874)

actually, increase is 102%

Re:double? (2)

Bill Dimm (463823) | about 3 years ago | (#36637888)

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%.

Re:double? (1)

thegarbz (1787294) | about 3 years ago | (#36638396)

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.

Re:double? (1)

MobileTatsu-NJG (946591) | about 3 years ago | (#36638476)

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.

Re:double? (1)

Anonymous Coward | about 3 years ago | (#36638600)

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.

Re:double? (0)

Anonymous Coward | about 3 years ago | (#36637784)

so if you caught a 51% off sale at the dollar store you don't think you could afford to double your purchases?

Re:double? (0)

Anonymous Coward | about 3 years ago | (#36637806)

51% reduction in power usage doubles battery life...just as the article says

Re:double? (0)

Anonymous Coward | about 3 years ago | (#36637852)

Yes, a 50% savings doubles battery life. There is nothing particularly interesting about 1/(1-.51)=2.04 battery life.

Re:double? (1)

Tumbleweed (3706) | about 3 years ago | (#36637890)

Yes, a 50% savings doubles battery life. There is nothing particularly interesting about 1/(1-.51)=2.04 battery life.

But that .01 could be the difference between hacking the Gibson or not!

Re:double? (0)

Anonymous Coward | about 3 years ago | (#36637882)

Only if all of the battery power is dedicated to the wifi radio. Not too likely with most useful devices.

Re:double? (0)

Anonymous Coward | about 3 years ago | (#36637892)

Yes it is you retard. It's a reduction.

Re:double? (2)

robmv (855035) | about 3 years ago | (#36637894)

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

Re:double? (1)

Tumbleweed (3706) | about 3 years ago | (#36637936)

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

Re:double? (1)

Nethead (1563) | about 3 years ago | (#36638020)

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.

Re:double? (1)

Tumbleweed (3706) | about 3 years ago | (#36638048)

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.

Re:double? (1)

cdrguru (88047) | about 3 years ago | (#36638390)

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 works out and interestingly it never seems to save money for the consumer.

Re:double? (1)

Tumbleweed (3706) | about 3 years ago | (#36638426)

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.

Re:double? (1)

Nethead (1563) | about 3 years ago | (#36639798)

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.

Re:double? (0)

Anonymous Coward | about 3 years ago | (#36638392)

Wifi is useful for more than just speed. Sometimes you are out of the coverage area. Sometimes you just don't get service because of the way the building is designed. Sometimes service is not even possible, like on an Airplane. Also, on an airplane, maybe you have your laptop with you, but they charge more for laptop WiFi than they do for mobile WiFi. On a short flight, you might not want to pay that extra money.

Re:double? (1)

stoanhart (876182) | about 3 years ago | (#36638802)

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.

enlighten me (1)

metalmaster (1005171) | about 3 years ago | (#36637896)

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?

Re:enlighten me (1)

SuricouRaven (1897204) | about 3 years ago | (#36637970)

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 (4, Informative)

TheRaven64 (641858) | about 3 years ago | (#36638320)

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.

Re:enlighten me (1)

Anonymous Coward | about 3 years ago | (#36640166)

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 periods where the client won't be listening for traffic and queuing traffic on the AP until the client collects it.

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

Re:enlighten me (1)

Deathanatos (811514) | about 3 years ago | (#36645578)

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 mention that. (But, for what one is doing on a mobile device, it probably won't matter.)

Therefore, to amortize the wake-up cost, PSM clients are made to wake-up less frequently, permitting multiple packets to queue up at the AP. Of course, such queuing introduces latency in PSM packet delivery.

The article then improves upon this method, but I didn't see if they actually did anything to remove the latency. I also didn't read the whole 13 pages of research.

Re:enlighten me (1)

tlhIngan (30335) | about 3 years ago | (#36653224)

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 periodically (typically every 10ms) sends out a beacon frame, which not only tells about it's presence, but also contains a traffic bitmap that says "I have traffic for these adapters". An adapter can work in two modes - always on (or always receiving) so it can get data the fastest, or in a store-and-forward type mode where the AP can buffer.

When a client associates with an AP, it negotiates with the AP on a parameter that basically says "I will wake up ever N beacons to retrieve my traffic". Yes, it's a balancing act - a larger N means the client can turn off the radios more (more power savings), but at the cost of increased latency and consumed AP resources (the AP has to buffer packets for the client in the meantime).

Depending on the application, this increase in latency may have little effect (does it matter if your email client gets the IMAP notification delayed by a second?). It should be noted that it's possible to go between modes so if you're surfing the web, during the data transfer it remains on as it's being actively used and going into sleep states just doesn't make sense (the network connection is active), then when the transfers stop, it goes back into the sleep state.

As a side effect, if the wifi adapter can go into sleep more often and check traffic less frequently, it's also generating less CPU interrupts, letting *it* go into low power states as well, which saves power.

Re:enlighten me (0)

Anonymous Coward | about 3 years ago | (#36657484)

You need to read the RFC's. ACKs are generated at least once for every two segments received. Window size determines the the amount of unacknowledged data that can be in flight at any given time. Window size does not change the ratio of segments to ACKs. This horrible misconception continues to be spread both on the web and in classrooms.

Re:enlighten me (1)

rrohbeck (944847) | about 3 years ago | (#36638854)

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.

Bluetooth "Sniff mode" for WiFi? (1)

Loopy (41728) | about 3 years ago | (#36639824)

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

Year old (0)

Anonymous Coward | about 3 years ago | (#36640146)

This kind of news was fresh one year ago. In June 2010 I reviewed a MSc paper written in Finland that had mostly the same results. It was probably sposored by or reladet to Nokia since the hardware they used was used in Nokia phones for Wifi.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...