This is especially crucial since LAN switches are always-on devices, and those with power efficiency can result in millions of dollars of operational expenditure savings annually. Enterprises must conduct the same kind of testing for power efficiency that they perform to determine
To address this problem, The Tolly Group -- which has released a series of best practice guides for network device testing -- has produced a playbook for testing LAN switch power consumption. Tolly's test sets benchmarks and parameters for measuring layers 2-3 LAN switches and layers 4-7 LAN switches (also known as load balancers, application switches or applications delivery controllers).
In part 1 of this two-part series, we will explain metrics for measurement and other considerations for LAN switch power consumption and efficiency. In part 2 of this series on testing for LAN switch power consumption, we will outline methods for measurement.
Elements to consider in LAN switch power consumption testing
A number of factors can affect the way power is consumed on a LAN switch. The network interface -- copper vs. fiber -- will affect power consumption, as will the number of active ports and the number of software modules needed to enable transport at some layers of the network.
Also, the deeper the inspection of traffic, the more power is used. Layer 4-7 switches have their own testing needs because switches make decisions based on data higher in the protocol stack and deeper in the packet. That drives a different code path, which could affect power consumption.
Test metrics for LAN switch power consumption
A number of metrics must be set in order to conduct objective testing.
Steady-state power draw
When we use the term steady-state in the context of performance testing, we mean that the system is running in a state that it can maintain indefinitely. From a power consumption standpoint, this is not as clear-cut. For example, fans running will certainly add to the power consumption. Since some vendors might "test" the fan by having it run when the system starts (even if it is not needed at the time to vent off heat), we have determined to begin testing of power consumption five minutes after the device is initially powered on in order to allow startup tests -- which might temporarily increase power draw -- to conclude.
Furthermore, one must determine whether steady-state power draw is based on a device with active but idle ports, or a device processing traffic.
Regardless of the definition used, it is important to note that energy cost calculations based solely on steady-state power draw are not likely to be accurate because, over the course of time, the switch will not remain in a single state with respect to traffic load and other aspects of operation.
To get an accurate measure of power, tests must note all modules that are being used in the system. In the case of "stackable" or fixed-port switches, though, it is also possible for optional modules to be present, which would potentially affect power draw. Typically, these would consist of uplink and/or stacking ports used to connect the backplane of one switch to the backplane of another switch in the group.
Impact of power supply
For systems that provide multiple power supply options, power supplies typically operate at their most efficient state when the load on them is between 50% and 90%, so power supply selection is important. For modular systems that are lightly loaded, selecting the highest-power capacity supply for the system will result in inefficient operation of the power supply and higher power consumption than utilizing a lower-capacity power supply operating closer to the midrange of its capabilities.
In the second part of this series, learn methods for measurement of LAN switch power consumption and energy efficiency.
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.htmlto read more of The Tolly Group's LAN Switch Power Consumption RFP, or to learn more about the Tolly Common RFP project.
This was first published in November 2009