Power Testing - Again, and More

You know how sometimes you start down a particular path and things just get more interesting as you go? And you wind up spending a lot more time than you thought you would, as the problem gets deeper and more complex? And you look up, after a few weeks, and wonder where all the time went?

If so, you might be a nerd (but not necessarily a geek, which is a nerd with no social skills), and you might spend a great deal of time studying power consumption in wireless LAN systems. I originally got started in this via a call from another analyst, questioning whether Siemens' 802.11n AP could really be powered via 802.3af PoE. Some testing later, the answer was clear - yes, it could. Other vendors, most notably Bluesocket and Meru, have since called with word that their .11n APs can also run on .3af power, and other vendors have solutions which range from graceful degradation in performance to proprietary PoE solutions (to, I am sure, full compliance with 802.3af). I expect everyone will eventually offer some form of .3af-compliant product, because the market will demand such, and because, again, consuming no more power than one really needs is always a good idea. But I also have to concede that we'll inevitably need to move on to .3at PoE and possibly some additional proprietary PoE solutions because there's also a demand to simply put more in an AP - witness, for example, Meru's new four-radio AP440 .11n product and the arrays available from Xirrus. No way these are going to run on .3af, and that's that.

So, anyway, I'm out in California this week doing some additional infrastructure PoE testing; more on that shortly. But I also just completed a study (published in Network World) of the behavior of 802.11's Power Save Mode (PSM), which has been in the 802.11 standard since the beginning. This is a simple technique - when PSM is enabled, the client radio will go into a low-power mode ("sleep") for a period of time, and then wake up to see if the AP has any traffic pending for it. If it does, the client will wake up and go into a normal dialog with the AP, and, if not, it goes back to sleep. This is a synchronous technique; asynchronous power-save modes have also been defined, most notably WMM Power Save from the Wi-Fi Alliance. Asynchronous means that the client can notify the infrastructure when it has something to send, coming out of power save when it needs to rather than waiting for the proscribed time period. This is obviously useful for time-bounded traffic like voice, and I expect such will be quite beneficial when it is widely implemented and available. And there are other sophisticated techniques associated with 802.11n, which otherwise could be quite a power hog indeed.

The procedure in my testing was simple - run a file transfer until the battery gave out, noting both elapsed time and the amount of data sent. A delay was introduced between transfers so as to allow the client to enter Power Save Mode. Note that the transition between Constantly Awake Mode (CAM) and PSM is defined in .11, but highly implementation-dependent - it's up to the equipment vendors to decide how and when and for how long to enter PSM. So I tested a bunch of these, and the results were not pretty.

I'll let you read the article for yourself, but suffice it to say that, given the conditions of the test, PSM isn't very helpful in getting longer batter life, and can be quite harmful in terms of throughput. Now, a reader, Eduardo Fisher (see his comment associated with the article) noted that PSM would be more effective if the radio was used less, and I even had text to that effect in the first draft of the article. But I took it out because such seems obvious - you can indeed get more battery life by not using the WLAN or simply shutting it off. But what's the point of that? We could eliminate air pollution and (perhaps) conquer global warming by parking our cars for good and eliminating the generation of electricity. But we'd also have to live without personal transportation and blogs.

OK, some of you might think that would be just fine. And it might also be possible to design another test that involves far less LAN traffic to see if the effect on battery life might be improved (and the negative impact on throughput might be lessened). But that wasn't the objective of this test, and the results are in concert with those I've seen in other more informal testing that I and others have done in the past.

I have much greater hope for the asynchronous power-save modes, and I'll return to those in the future. And I'll have the new infrastructure power tests for you shortly as well.

Join the discussion
Be the first to comment on this article. Our Commenting Policies