## 6 Evaluation
### Simulations
#### 6.1.2 Simulation Results
Figure 7 shows how the network conditions affected the makespans and data localities. Because Hadoop and DELAY are not sensitive to the changes in network conditions, their makespans increased significantly when the network factor changed from 1 to 4. DynDLOn increases the delay time to decrease the chance of assigning multiple data-remote tasks to the same server, so its makespan increased slightly. From Figure 7b, DynDLOff's data locality was worse than other offline algorithms'. This is because the initial loads were chosen from [0, 1000]. DynDLOff assigns more data-remote tasks to reduce the negative effects of the large initial loads. When we performed simulations that set \(\beta\) to 100, all the algorithms (except Hadoop) made most tasks data-local. **Effects of network conditions. ** In these simulations, we set \(|T|\) to 100, \(|S|\) to 50, _core_num_ to 40, \(\beta\) to 1000, and \(\alpha\) to 0, and changed the network factor \(\theta\) to 1, 2, and 4. A larger \(\theta\) indicates the network conditions are worse, so a data-remote task needs more time to transfer data. Figure 7 shows how the network conditions affected the makespans and data localities. Because Hadoop and DELAY are not sensitive to changes in network conditions, their makespans increased significantly when the network factor changed from 1 to 4. DynDLOn increases the delay time to decrease the chance of assigning multiple data-remote tasks to the same server, which increased the makespan slightly. **Effects of number of tasks. ** In these simulations, we set \(|S|\) to 50, _core_num_ to 40, \(\beta\) to 1000, \(\alpha\) to 0, and \(\theta\) to 1, and changed the number of tasks \(|T|\) to 200, 2000, and 20,000. Because there were 2000  
Figure 6: Effects of load skewness. Figure 7: Effects of network conditions. cores (\(core\_num\cdot|S|\)), the ratios of the number of tasks to the number of cores were 1:10, 1:1, and 10:1. Figure 8 shows how the number of tasks affected the makespans and data localities. When \(|T|\) was 200 and 2000, DynDLOn and DynDLOff were 20% and 10% better than other algorithms in terms of the makespan, respectively. When \(|T|\) was 20,000, HTA took more than half an hour, so we did not mark HTA's makespan and data locality as \"timeout\". Except for LIST, we found that all the algorithms' makespans were close, and most algorithms did not assign data-remote tasks. This is mostly because the number of tasks was 10 times larger than the number of cores. In this case, the algorithms more easily selected data-local tasks, so they performed similarly. **Algorithm running time. ** In these simulations, the default settings were \(|S|=1000\), \(core\_num=10\), \(t=10\),000, \(\beta=1000\), \(\alpha=0\), and \(\theta=1\). We changed the number of tasks \(|T|\), the number of cores in each server \(c\), and the number of servers \(|S|\), and measured the offline algorithms' running time, as can be seen in Figure 9. When \(|T|\) was changed from 500 to 3500, the running time of LTFPA, BAR, and DynDLOff changed from 15.11 to 18.03 milliseconds (ms), from 52.12 to 302.45 ms, and from 39.22 to 124.21 ms, respectively. Although the running time of DynDLOff was longer than that of LTFPAin Figure 9a, we show that DynDLOff was faster when the number of servers increased. When \(c\) was changed from 10 to 70, the running time of LTFPA and BAR was stable, but that of DynDLOff increased from 49.21 to 107.21 ms. This is because DynDLOff took the multicore-based server into account. However, because most servers had less than 100 cores, the upper bound of \(c\) was a constant and the running time of DynDLOff was bounded. When \(|S|\) was changed from 100 to 1000, the running time of LTFPA, BAR, and DynDLOff changed from 9.76 to 655.76 ms, from 229.11 to 1010.89 ms, and from 83.56 to 341.67 ms, respectively. From Figure 9c, we see that when \(|S|\) was larger than 400, the running time of DynDLOff was shorter than LTFPA's. This is because the running time of LTFPA's load-balancing phase increased with the number of servers.