One of the challenges in mobile computing is battery life. It's hard to be productive with a dead battery, so IT personnel and users alike need to think about maximizing run time between charges.
Optimizing the power conservation settings of a mobile computer or communicator, including dimming the display when on battery, turning off the display and hard drive after a pre-set period of time, suspending (keeping memory alive but the computer otherwise powered down) and hibernating (writing the image of main memory to disk for later resumption) help in getting the most out of any given charge. (Read a related story on how to get the most out of your battery.)
And there are also power conservation settings in most Wi-Fi adapters that (at first glance, anyway) are intended to allow a high degree of control over the power consumed by the wireless network interface card (NIC) found in almost all notebooks and many handhelds as well. In gross terms, wireless power conservation involves turning off the radio, synchronously or asynchronously with the fixed infrastructure, for a portion of time - a technique used in various forms on essentially all production wireless systems today, including WANs. But this technique motivates an interesting and fundamental question: do Wi-Fi power-conservation techniques, when enabled, actually save a meaningful amount of energy or have any negative impact on throughput?
We set out to define a simple test to answer these questions as they pertain to 802.11's Power Save Mode (PSM), the most common form of Wi-Fi power saving implemented today. We do note that there are several new power saving mechanisms defined for 802.11n (see related story on standards) gear, but we have not found those to be widely implemented, so we could not assess those at this juncture.
Vendors have delivered a number of PSM variants, with the primary difference being how quickly and how often the adapter wakes up. Having a NIC wake up faster could negatively affect power consumption, the fundamental tradeoff in this strategy, although this could theoretically improve throughput. The opposite of PSM is Constantly Awake Mode (CAM), in which PSM is disabled. Our test compared various forms and implementations of PSM against CAM and, for good measure, a wired gigabit Ethernet baseline test.
Using PSM in our tests produced only a marginal benefit in terms of battery life (and was even slightly worse than CAM in one test). In terms of throughput, the results ranged from marginally positive to having a very negative impact on throughput in two cases tested
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bottom line: PSM isn't likely to be of any value in contemporary implementations, and may even hurt performance.
We contacted all vendors whose products were included in this test regarding the results. Only Broadcom's PR department would comment, saying that its internal testing showed that battery life gains from PSM implementations in notebooks varies between brands, sometimes showing that PSM can maximize battery life with no impact on throughput.
Test configuration and procedures
The basic test strategy was to copy a file consisting of roughly 1MB (1,095,680 bytes, to be precise) from a source computer to a destination computer as many times as possible, beginning with a fully charged battery and ending each test run when the notebook computer went into hibernation as a result of near exhaustion of the battery, defined in this case as 5% battery charge remaining.
The test was driven by a simple DOS .bat file, the logic for which was to print the time of day, copy the file from source to destination, pause for three seconds, increment and display a counter indicating the loop iteration, and then run continuously until the battery gave out. The purpose of the pause was to allow more than enough time for the notebook to go into PSM and to simulate a fairly low Wi-Fi usage duty cycle, so as to maximize the time the radio was asleep. The test script was run on the destination computer so that transactions would be initiated and recorded by the mains-powered computer.
The destination in all test cases was a Dell 4500 desktop upgraded with a PCI gigabit Ethernet adapter and running Windows XP Pro with all current updates applied as of the date that testing began. Power conservation features on this machine were disabled for all test runs as it was operating on AC power.
We used two different source computers, both notebooks: an Acer Aspire 5920 notebook equipped with Vista Ultimate (including all updates available as of the date of the test run, but not including SP1), and featuring both gigabit Ethernet ports and an integral Intel 4965 a/g/n wireless adapter; and an HP Compaq nx6125 with gigabit Ethernet and a Broadcom 802.11 b/g radio.
Both machines were directly connected to each other either via a gigabit Ethernet link (for baseline testing), and via a wireless connection (using an access point). At no time were any elements connected to any other network or the Internet.
The Acer's built-in wireless adapter was used in 802.11g mode only, with a Netgear WNR854T router (used only as an access point in this test) forced to 802.11g mode as well. The Acer internal adapter was also used in 802.11n mode with a Linksys WRT350N router (again, as an access point). Similar 802.11g testing was performed with the HP notebook, using the Linksys AP, and also with two external 802.11n adapters (a Linksys PC card and an SMC USB adapter) connected to the Linksys AP. All of this provided a good variety of test cases.
Our test procedure involved first establishing a baseline for performance in terms of throughput. We then repeated the test with each Wi-Fi client adapter/access point pair, in each case the only variable being the changing of the level of client Wi-Fi power conservation. Both notebooks kept the hard drive on all the time, and the Acer was set to 50% display brightness while the HP's display was kept all the way up. We used a spectrum analyzer to monitor for any high-amplitude interference that might affect results throughout all test runs, and none was observed.
Less than satisfying results
What jumps out almost immediately from this data is that PSM in any form delivered very little in terms of additional run time, and occasionally had a major detrimental impact on throughput.
The best improvement in runtime that we saw was a little over 8% in the case of the Linksys AP/Linksys Adapter running on our HP notebook with PSM enabled. That said, this combination also simply decimated throughput to less than half that of the CAM case. Interesting, this same combination of gear with "Fast" PSM enabled still resulted in 4% better run time and yielded a .5% gain in throughput.
Overall, though, it was clear that PSM was not contributing to significantly longer runtimes, and thus appears to have a negligible impact on notebook battery life. Moreover, in most cases, throughput was adversely affected and, where it was not, no real benefit was noted.
And the reason for this is the relatively large amount of power consumed in modern notebooks in comparison with the energy used by today's Wi-Fi adapters.
The 802.11 standard was initially developed during a time when processor clocks were in the 100MHz to 200MHz. range, and initial WLAN designs involved a significant number of power-hungry components. Today, however, Wi-Fi adapters are highly integrated -- meaning fewer chips are required to implement a Wi-Fi solution -- and designs are more power-efficient. While the notebooks' other components -- most notably the processor (because of higher clock rates) and display and backlighting (due to much higher resolutions) -- often consume more energy than in the past.
Notebook designers have compensated with larger batteries and a continual emphasis on power-conservative designs and provisions for a high degree of end-user control over power conservation settings in many cases, but the proportion of energy consumed between the computer and the WLAN adapter has clearly flipped.
As a consequence, it would be hard to encourage users to enable PSM in their daily operations. PSM is mostly harmless, but can also have very negative performance impacts. We also noted in the testing of some of the power-save modes on the Intel adapter that test runs would not complete, timing out with an error message, indicating that the notebook was simply not responding fast enough to meet application demands. Users thus need to be cautioned about setting PSM options without some knowledge of the possible consequences.
Saving energy in any form is, as Martha Stewart might say, a good thing. But, more importantly, anyone who is mobile knows that, after dropping one's mobile computer or communicator on a concrete floor, the most likely failure mode for these devices is a battery going dead. While I still recommend carrying a fully charged spare battery for all critical mobile devices essentially everywhere (understanding that is problematic with notebook batteries that tend to be large, heavy, and expensive), anything we can do to optimize battery life without creating a significant impact on network throughput needs to be considered, if not implemented as a matter of policy. Our tests show, however, that a slam-dunk case for Wi-Fi Power Save Mode cannot be made.
As a final note, it's also important to point out that we've only been considering the client-side elements of power conservation. While infrastructure plays a critical role in the implementation of the protocol-related elements of WLAN power management, it also makes sense to examine the power, and thus the cooling and cost, impacts of all WLAN infrastructure-side equipment, most importantly access points. While not all 802.11n access points, for example, can run on 802.3af power over Ethernet, it is wise to consider access point power consumption when evaluating new equipment. While this may not be the deciding factor in a purchasing decision, it makes sense that such at least be an item in the RFP.
Mathias is a principal with Farpoint Group, an advisory firm specializing in wireless networking and mobile computing. He can be reached at craig@farpointgroup.com.