## 6 Evaluation
### Real Execution
#### 6.2.2 Real Execution Results  
We performed two experiments on the testbed, which simultaneously ran 50 and 100 jobs, respectively. Figures 10 and 11 show the two experiments' total job completion time and data locality. From Figure 10, we see that DELAY3's job completion time increased significantly when the data block's size increased due to data locality. Because DELAY3's delay threshold (3 s) was much shorter than the average task running time (7 s), it assigned more than 200 data-remote tasks.  
Figure 9: Algorithm running time.  
Compared to DELAY3, DELAY6's and DELAY10's delay thresholds were longer, assigning 8 and 0 data-remote tasks, respectively. Their job completion times were one-fourth of DELAY3's. Regarding DynDLOn, its job completion time increased from 34.82 to 59.48 s when the data block's size increased from 64 to 512 MB. Although its initial delay threshold was only 3 s, its data locality was much better than DELAY3's. For example, when the data block's size was 512 MB, it assigned 36 data-remote tasks, but DELAY3 assigned 230 data-remote tasks. DynDLOn assigned fewer data-remote tasks when the data block's size was larger, which illustrates that DynDLOn can adaptively change data locality according to the network conditions. This is because DynDLOn will not assign more data-remote tasks to a server when the server is running a data-remote task. Although it assigned more data-remote tasks than DELAY6 and DELAY10, its job completion time was shorter when the data block's size was smaller than 256 MB. This is because DynDLOn's delay time is shorter and it does not concurrently run two data-remote tasks on the same server. When the size of the data block was 512 MB, DynDLOn's job completion time was longer than that of DELAY6 and DELAY10, because transferring a data block takes 10 s, so DELAY6 and DELAY10 assigned fewer data-remote tasks. However, a longer delay threshold may introduce a larger delay cost, so DynDLOn is still competitive in job completion time.  
DynDLOn is more adaptive than the delay scheduling algorithms, as can be seen in Figure 11. We can see that when the number of jobs increased from 50 to 100, DELAY6's performance decreased significantly. When the number was 50, only 2% of the tasks were data-remote, but when the number of jobs was 100, nearly 50% of the tasks were data-remote. Moreover, for 512-MB data blocks, when the number of jobs was 50, DELAY6' job completion time was close to DynDLOn's, but when the number of jobs was 100, DELAY6' job completion time was 6.5 times longer than DynDLOn's. This is because a data-remote task's running time was more than 10 s, larger than DELAY6's delay threshold. When the number of jobs increased from 50 to 100, more tasks were data-remote. Then, it was likely that multiple tasks would run on the same server, so the running time increased. Furthermore, the tasks' average running time was longer than DELAY6's delay threshold, so the number of data-remote tasks  
Figure 11: Results of running 100 jobs.  
Figure 10: Results of running 50 jobs.  
also increased. DELAY10's performance was not affected by the number of jobs. Because the tasks' running time was randomly selected from [2; 12], the 10-s delay threshold was long enough to wait for data-local servers. However, this makes it difficult to choose a proper delay threshold that suits all the situations. As stated above, DynDLOnis more adaptive than the delay scheduling algorithms. So, we do not need to define the delay threshold precisely, because DynDLOn's performance is stable for any given scenario.