Vendors promise energy-efficient networks, but they often can't prove actual usage on components. As a result, enterprise users must implement formal testing of LAN switch energy efficiency through the same kinds of performance tests they use to determine speeds and feeds and functionality. In the first part of this
best practices guide for testing LAN switch power consumption by The Tolly Group, we covered the necessary test metrics for measuring LAN switch energy efficiency. In this edition of the series, learn the methods of measurement for LAN switch power consumption testing.
Methods of system measurement for LAN switch power consumption
A single test often provides multiple measurements or different ways of looking at the same data. The following are some measurements to consider when it comes to testing LAN switch energy efficiency and power consumption:
In switch performance tests, throughput is typically the most important measurement. It is also an important measurement when benchmarking power consumption. These numbers are used along with the measured power consumption to calculate how much throughput is achieved per watt of power usage.
We recommend that testers include a calculation of megabits per second per watt (Mbps/Watt). Gigabits can be used alternatively, where appropriate. Users can also take the raw data and calculate pounds of carbon per megabit per second.
Throughput measurements are also important because some manufacturers have chosen to implement networking architectures that cannot provide wire-speed throughput to all interfaces attached.
Such switches have card modules and/or backplanes that are "oversubscribed." These might use less energy than devices that do offer full, line-rate throughput.
Without throughput measurements, one might erroneously conclude that a device with lower capacity was more efficient than one that can deliver greater throughput from an equal number of ports. With throughput brought into the calculation, one can correlate the throughput achieved for the power expended.
Power factor as a consideration in testing LAN switch energy efficiency
Perhaps as important as the absolute measure of power consumed is quantifying the efficiency with which the power is being used by the DUT.
According to Wikipedia.com, power factor is "the ratio of the real power flowing to the load to the apparent power." Inefficient use of power means that the device consumes more energy than it is actually able to use, and thus long-term power consumption costs are higher than they need to be.
Power factor (pf) is a number between zero and one, with "one" representing maximum or 100% efficiency. Test tools such as the "Watts Up" will calculate this value automatically. The apparent power consumed by a system is the product of the RMS values of the voltage and current across the device, assuming that the waveforms are in phase. This value is used by power suppliers to assess the total energy used. The problem is that, more often than not, the voltage and current waveforms will not be in phase due to the complex series of networks within the device.
This measurement occurs only when dealing with an AC power source and can be disregarded for DC systems.
Considering traffic load in testing for power consumption
It is important to have different load levels in order to get an accurate profile of consumption with varying degrees of network activity. Note that the port state of connected and open means not only that the cable is connected but that the physical and mac layers are active.
Percentages listed under load are of theoretical maximum for the device as configured.
Tolly recommends that tests be run as follows:
Frame/packet size makes a difference
Historically, layer 2 and layer 3 switch tests have been run with a range of frame/packet sizes from the smallest legal size of 64 bytes to the largest standard size of 1,518 bytes, with additional tests done at various sizes in between, most commonly 128, 256, 512 and 1,024. Some tests also include nonstandard, "jumbo" frames. These can be as large as 16,000 bytes but are typically tested at approximately 9 Kbytes or 9,128 bytes. For the purposes of layer 2 and layer 3 power consumption tests, it is not necessary to test all of these frame/packet sizes.
While there is no industry standard with respect to which frame size to use when benchmarking power consumption, one should keep in mind that, typically, a "worst case" scenario would consist of a test that used only 64-byte frames. Such a test forces the switch to process that maximum number of packets and would typically drive its power consumption to the maximum.
Conversely, a test of larger data payload sizes like 1,518 bytes or jumbo frames reduces the number of frames processed per unit time and, depending again upon the device architecture, could lower the power consumption. In any case, one should note (and test results should document) the frame size(s) used for a given test.
Testing at layer 4 and higher will consist of actual traffic flows (e.g., session setup, data transmission, session teardown). By its very nature, such traffic will consist of a mix of frame/packet sizes. Thus, as one tests at these layers, the notion of a stream of one-size-only traffic disappears.
It is important to realize, though, that the idea of processing "smaller" and "larger" units of data does exist in layer 4-7 testing. This unit of data will be indicated in tests as the "object size," that is, the size of the object that is being returned from the server to the client across the switch. It is important to note that these object sizes can be, and very often are, larger than the maximum standard Ethernet frame size of 1,518 bytes.
Considering traffic types for LAN switch energy efficiency testing
Switches process traffic in hardware or software or a combination of both, depending upon the nature of the traffic. While switch vendors rarely disclose this level of detail, it is important for the tester to understand that "software" vs. "hardware" can have an impact on switch power consumption.
When a switch cannot process certain traffic relying on the hardware chipset and must rely on software running in the main processor, that necessarily increases CPU utilization, which in turn increases the power draw.
Thus, in measuring power draw, it is important that the traffic type and traffic blend be applicable to your intended use. While most (if not all) switches will process layer 2 traffic in hardware, some switches process some or all layer 3 (routing) functions in the main CPU.
It is sometimes confusing trying to understand what "layer" traffic is being processed. The key is to remember that it is not necessarily the content that determines the layer, it is the switch capabilities and settings. One can, for example, send layer 7 http traffic through a layer 2 switch, but that switch will be making decisions based only on layer 2 information. Thus, the results would be the same whether the traffic packets contained application data or nothing more than just legal layer 2 address information.
Remember that just because you are transmitting upper layer traffic, you cannot simply assume that the switch is processing at a particular level unless you build your test plan to prove that traffic is being directed by content at a particular level in the protocol stack. As an example, many layer 7 tests will be designed to direct the switch to send traffic to a particular port based on the webpage being requested across the connection. In such cases, it is easy to prove that processing is being executed at a certain level in the stack by verifying that the target servers that should be reached with a given "Get" request are reached.
To see specific test permutations and configurations for layers 2-3 and 4-7 switch testing, see the full report, The Tolly Group RPP 1080: LAN Switch Power Consumption.
About the author:
Kevin Tolly is president and CEO of The Tolly Group, an independent test lab and research firm. Visit http://commontestplan.org/Plans/1080.html to read more of The Tolly Group's LAN Switch Power Consumption RFP or to learn more about the Tolly Common RFP project.
|Permutation #||Port State||Traffic Load|
|2||Active (Connected and Open)||None|
This was first published in November 2009