# Improving Energy Efficiency on SDN Control-Plane Using Multi-Core Controllers
## 4 Simulations and Results
### Evaluation for Constant Throughput (Iperf)  
The Iperf utility was used to create a constant throughput flow from one host to the other passing through the controller. This scenario puts the controller under a steady and heavy but controlled load, a common pattern for applications such as video streaming. The Iperf tool was chosen as the traffic generator because it is a well known and widely used tool to generate and measure network throughput. Many researchers [35; 36; 37] consider it a good model for evaluating performance of various network elements. The use cases range from energy-efficiency tests in SDN [35] to statistical analysis of SDN management [36] including security strategies [37]. The Iperf tool is used to validate experiments and creates test traffic that correlates closely to real patterns. The controller used for the experiment was a Ryu [28] based multicore controller running on a quad-core server (Dell PowerEdge R230) with an Intel Xeon E31220 processor. The vswitches and hosts were simulated using Mininet [38] utility on separate hardware (Dell Inspiron); the energy consumption measures were done on the server running the controller. The first measurement in Figure 8 was done keeping a constant throughput of 30 Mbps over a 600 s period. The same experiment was done for 1-4 cores. The single-core instance keeps an almost constant energy consumption near 10.2 J, while the multicore versions run an average as low as 7.1 J. The few dips shown on the graphs represent moments where the processor was idle, waiting for I/O to happen. The other two experiments were done increasing the load on the controller: 40 Mbps depicted in Figure 9 and 50 Mbps in Figure 10. In these two experiments, only 2-4 cores instances were used since the single-core instance could not deliver the throughput expected even on the highest available frequency (3 GHz). The energy consumption could still be optimized from the two-core instance to the three- and four-core ones, from 9.6 J to an 8.0 J on average. Another important finding is that the dips in the graphs for higher throughput are fewer on the 40 Mbps than the 30 Mbps one and even fewer on the 50 Mbps one, which means that the processor has much less idle time, pushing the energy consumption higher. Figure 11 shows a comparison of the CNEE metric, defined in (2); even though a single core may deliver the agreed throughput, more cores with lower frequencies bring more efficiency. On the other hand, as shown by [PERSON] et al. (2018), there are limitations on efficiency gain related to the application's characteristics, namely the serial and parallel fractions, as discussed in Section 3.4. The gain is limited by the serial fraction of the problem, by the Amdahl's law. Figure 8: Energy consumed during the last second that proceeds the measurement for different number of cores during a 30 Mbps traffic. Figure 9: Energy consumed during the last second that proceeds the measurement for different number of cores during a 40 Mbps traffic. As can be seen, the 40 and 50 Mbps scenarios could not be delivered by a single-core controller even on the highest available frequency (3 GHz). In our scenarios, the three-core configuration shows better efficiency. This is not a general rule as the best configuration will depend on the controller's implementation and the network's demand from the southbound and northbound interfaces. As stated by [PERSON] [25] and discussed in Section 3.4, larger problems would benefit from more processors if the problem's parallel fraction also grows accordingly. Here, the behavior shown in Figures 5 and 6 supports the assumption that, with higher throughput, the parallel fraction will be distributed evenly by the cores, hence leading to better energy efficiency on the four-plus-core instances; not only the throughput but also as the number of users of the northbound controller interface grows. Figure 11: Communication network energy efficiency for different multicore scenarios.