At the Office of the CTO, we are using a data-driven approach to discover possible ways to conserve energy for our customers. Our engineers have built an energy metrics collector and have begun collecting useful data.
In April, I wrote a blog to celebrate Earth Day titled, “Who’s Going to Save the Polar Bears? Environmentalists, Politicians, or Engineers?” This blog was the first in a series of “green” blogs about the enterprise networking industry and how technology innovation can help us be more intelligent with energy consumption.
In the second blog of the series, I introduced you to an Office of the CTO project called the Energy Metrics Data Collector. We are using a data-driven approach to discover possible ways to conserve energy for our customers. In this blog, I will begin sharing insights into the data we are collecting from the metrics collector we have built.
For this project, we run a script to collect all Wi-Fi data and store it in our monitoring system’s database. The script retrieves various metrics in a 5-minute interval and stores 1-hour aggregates within the database.
As we begin this interesting phase of this project, let’s take a first glimpse into the environment of a large Wi-Fi customer, a university with 370 access points. After the first six days of data collection, we analyzed the data and built the dashboards shown in the figures in this blog.
Figure 1 – Overall Wi-Fi energy
As shown in Figure 1, the energy consumption is broken down by access point model. The majority are the AP510 model, which is a 4×4:4 access point that should consume more energy than the AP410 model, which has fewer radio chains. You might ask, “why are the lines almost perfectly flat?” Although there is some slight variance over time, it is not visible in this dashboard as the data is aggregated per hour – with hundreds of APs, there are no peaks visible – data is “averaged out.” This is a common pitfall in data analysis that we should avoid. In addition to the challenge of using averages, another factor is the scale of the y-axis in dashboard charts. As shown in Figure 1, the range is large (0 watt hours [Wh] to 3500 Wh). Because of this wide range, if one line fluctuates only slightly, for example, 3450 to 3500 Wh, you won’t see that fluctuation in the chart.
Let’s use the overall energy consumption totaling 447 kilowatt hours over six days to estimate how much money this costs the customer. Based on the country of origin of this customer, we will use a price of $0.30 per kilowatt hour as an estimate. Based on this rate, the cost to operate the APs for six days is roughly $134. Over the course of a year, this would amount to more than $8000. If you extrapolate to the future, where energy costs are expected to continue rising, the cost of operating a Wi-Fi infrastructure will increase significantly. This problem is compounded further because network switching infrastructures are even more costly.
Let’s dive a bit deeper to understand which factors could be driving energy consumption on the wireless network. We start by comparing the overall Wi-Fi energy consumption with three key Wi-Fi metrics:
Figure 2 – Wi-Fi key metrics
As seen in Figure 2, each chart has two datasets, each having a y-axis: the purple line always shows the same dataset, overall energy consumption, and uses the right y-axis for scale. The green lines show the three different metrics we want to analyze, and use the left y-axis for their scale.
We can see on this chart that the energy consumption correlates to all three factors. As more Wi-Fi clients connect to access points, an AP sends and receives more data, resulting in more power consumption. However, the power consumption only fluctuates in a small range. An AP’s power consumption appears primarily driven by its base consumption, not by the number of clients or traffic it carries. However, the current peak number of Wi-Fi clients connected simultaneously is around 700, which is a very light load considering the total of 370 access points. Therefore, to get a more precise result, we will follow up with this customer in October when most students return to campus and thus increase the load on their wireless network significantly.
We also analyzed the Power over Ethernet (PoE) consumption data retrieved from the customer’s switches, augmenting it with end-system type data we retrieve either from Link-Layer Discovery Protocol (LLDP) data or from the customer’s network access control (NAC) solution. This allows us to analyze power consumption per wired end-system type (VoIP phones, access points, etc.).
Figure 3 – PoE energy consumption
As seen in Figure 3, the top left chart shows that energy consumption during working hours fluctuates sharply every weekday, with a “cliff” at 19:00. The customer explained that this is due to the display settings of their VoIP phones – the phones automatically turn off their displays every day at 19:00. This is an excellent example of a measure that saves 0.5 kilowatt-hour (kWh), which is quite impressive given that this is only done for one networking device type. Also, note that while the VoIP phone displays are disabled, the phones remain powered for minimal functionality.
The total power consumption of 893 kWh includes the power use from all APs (447 kWh) as they are also powered using PoE. This demonstrates that other PoE-driven devices can have a significant impact on power consumption – not only the Wi-Fi APs. Often there is a common misconception that only APs are a significant drain on the power budget of a switch.
Finally, the chart below the overall consumption value of 893 kWh, displays how much PoE adds to the base switch power consumption. Operating the switches without powering PoE devices requires a little under 15 kWh of power. Adding PoE to the equation adds another 6 kWh of energy use, on average. This number will vary from customer to customer; however, it is common for numerous connected devices to use PoE and their impact on total consumption is significant (adding almost 50% on top of the switches’ base consumption).
We are entering an exciting phase of this initiative. Check back soon for the next blog, to learn what we might discover as we retrieve more data while also applying power-saving measurements and machine learning algorithms that will complement our “manual” findings.
