# Adaptive Computation Offloading with Task Scheduling Minimizing Reallocation in VANETs
## 6 Performance Evaluation
Figure 5(c) shows the number of SVs according to the number of searched vehicles. Actually, we can see that the number of vehicles that provide computation services in HEFT became equal to the number of SVs in HEFT when the number of searched vehicles was 8, which is twice the width of the DAG. This means if there are sufficient vehicles, VAO can give good performance. Figure 4: The road environment of the Veins simulation. The black line is rad and red triangles are vehicles. Figure 5: Initial schedule length without reallocation for a depth 4 and width 4 DAG application. The accumulated data transfer times during the execution of an application are presented in Figure 6d. While the data transfer time of Max-Min continuously increased, the data transfer times of HEFT and VAO barely increased once stable. This is because Max-Min considers only computation power of vehicles in selecting SVs, resulting in task offloading to an unnecessarily excessive number of SVs as \(|V|\) increases. On the contrary, HEFT and VAO select SVs considering data transfer time as well as computation power of vehicles in (1) and (3). Thus, although a neighbor vehicle has a little higher computation power, an RV does not offload tasks to the neighbor if the data transfer cost is too high. As seen in Figure 5, the initial schedule length by VAO is slightly longer than HEFT if there are not enough vehicles around an RV because some neighbor vehicles are excluded from the candidate SVs' set. However, in terms of reallocation overhead, VAO is better than others. Figure 7 compares the task reallocation probability of the three methods. This result comes from the same simulations in Figure 6. Only 15.2% of tasks were reallocated to others in VAO, whereas 60.6% and 86.2% of tasks had to be reallocated to others in HEFT and Max-Min, respectively. As a result, the schedule length by VAO, including reallocated tasks, was shorter than HEFT by 14.4%, although the initial schedule length by VAO was 11.7% longer than HEFT. The performance of the CO scheme can be different according to the depth and width of a DAG. Figure 8a,b illustrate initial schedule lengths associated with varying the depth and width of a DAG. While one of the width and depth was varied, the other was fixed at 4. In both graphs, as the depth or the width increases, the length of the schedules increases naturally, since the total number of tasks increases. Comparing \"large depth\" to \"large width\", the large width was better to create shorter schedule lengths because more tasks can be executed in parallel on more SVs. Figure 8b shows that Max-Min is also a good option in the case where the width is large. However, the width of a DAG can be widened only when tasks have no tight relationships with each other. If tasks have strict precedence relationships between themselves, only the depth can increase. Figure 8a shows that the schedule length difference between Max-Min and the other methods got bigger as the depth of a DAG increased. When the depth was 8, the schedule length difference between HEFT and Max-Min was 14.8 s, 7.7 times larger than the difference when the depth was 2. This substantiates the view that DAG scheduling is efficient for applications with a large depth. Figure 6: _Cont._  
Figure 6: Schedule length and data transfer time for a depth 4 and width 4 DAG application: (**a**) Schedule length against the number of searched vehicles; (**b**) Schedule length against the number of searched vehicles; (**c**) The number of SVs against the number of searched vehicles; (**d**) Data transfer time against the number of searched vehicles. Figure 9 represents the data transfer time with varying depth and width. Figure 9a shows the data transfer time of Max-Min was longer than that of HEFT and VAO by 18-20%. Meanwhile, Figure 9b shows that the data transfer times of HEFT and Max-Min became closer as width increased, and the difference was just 5.8% when the width was 8.