## 4 Proposed Algorithm (NCRA-DP-ACO)
### Pheromone Management
#### 4.2.7 Algorithm
#### 5.2.7 Total Computational Overhead

To evaluate the computational efficiency of NCRA-DP-ACO, we measured its cumulative execution time over a five-day simulation period across varying VM workload sizes, with each configuration tested over 30 independent runs (see Table 8). Experiments were conducted on a Lenovo (Lenovo Group Limited, Beijing, China) system with an Intel(R) Core(TM) (Intel Corporation, Santa Clara, CA, USA) i5-8250U CPU (1.60 GHz base, 1.80 GHz boost), 16.0 GB RAM, and NVMe (Samsung Electronics Co., Ltd. Suwon, South Korea) storage. The algorithm showed scalable performance, with total execution times increasing from 4983.96 s (about 83 min) at 500 VMs to 18,655.12 s (about 5.2 h) at 14,000 VMs. This trend reflects the natural growth in the solution space and constraint complexity as the workload size increases. A 13.6% reduction in time at 10,000 VMs, relative to the trend between 5000 and 14,000 VMs, suggests accelerated convergence due to pheromone reinforcement under balanced resource conditions. Overall, the performance consistency was robust: the standard deviation remained below 15% of the mean (8.6% [428.23 s] at 500 VMs and 10.4% [1934.12 s] at 14,000 VMs). This low variance persisted even under dynamic workload distributions and simulated renewable energy fluctuations. These results confirm that NCRA-DP-ACO is well suited for deployment in energy-conscious datacenters operating with batch-style placement cycles, deadline-sensitive cloud environments, and scenarios requiring high-quality VM allocation with predictable overhead. #### 5.2.8 Comparisons with Hybrid and Multi-Objective Algorithms

To strengthen the validation of NCRA-DP-ACO, we compared its energy efficiency (kWh/VM) with a range of state-of-the-art VM placement algorithms reported in the literature. The inferred energy-per-VM values for the baseline algorithms are listed in

Figure 5.3 SLA violation rates for proposed ACO and UACS for rising request numbers. \begin{table}
\begin{tabular}{c c c} \hline
**VM Workload Size** & **Average Execution Time (s)** & **Standard Deviation** \\ \hline
500 & 4983.96 & 428.23 \\ \hline
1000 & 9151.37 & 944.57 \\ \hline
5000 & 18,160.69 & 581.48 \\ \hline
10,000 & 13,640.21 & 1259.35 \\ \hline
14,000 & 18,655.12 & 1934.12 \\ \hline \end{tabular}
\end{table} 
Table 8: Average runtime per workload size. Table 9. The comparison includes multi-objective evolutionary algorithms (NSGA-III and GA + threshold), a hybrid metaheuristic (ABGWO), and other metaheuristics (ETA-ACO, ACO, and PSO) that target energy-aware scheduling. Where direct implementation was not feasible, our comparisons rely on published values and approximations. For several baseline algorithms where the energy consumption (in kWh) was not directly reported, we inferred the values using standard power modeling assumptions based on information provided in the original papers. For instance, in [46], the ABGWO algorithm utilized approximately 210 PMs to host 2000 VMs under Azure workload traces. Assuming a typical PM power draw of 200 watts at moderate utilization (40-50%, as suggested by cloud datacenter standards), the total system power consumption was approximated as 42 kW. Assuming a 1-h simulation duration--a default in many CloudSim-based experimental setups--the estimated energy usage is 42 kWh. Dividing this by 2000 VMs yields an approximate energy-per-VM value of 0.210 kWh. This method was similarly applied to other studies that reported power values in watts or server usage rather than in kilowatt-hours [47]. We normalized all per-VM energy values to a baseline of 5000 VMs to align with the scale at which our algorithm achieves efficiency using the following formula:

\[Normalized(kWh/VM)=\frac{Reported(kWh/VM)\times 5000}{Original\_VM\_Count} \tag{29}\]

Under this normalized evaluation, NCRA-DP-ACO achieves the lowest per-VM energy at 5000 VMs--0.169 kWh/VM--demonstrating its scalability and energy awareness in large-scale cloud environments.