# Efficient Dynamic Deployment of Simulation Tasks in Collaborative Cloud and Edge Environments
## 4 Design of Pool
### Reassigning of Tasks
For parameters \(\alpha\), \(\beta\), \(\gamma\), and \(\lambda\), they were all derived from a uniform distribution. Considering that skewed distributions with long tails are much more common in computer workloads, gamma distribution was adopted to generate \(d_{i}\) and \(s_{i}\) for task \(i\). As migration cost of each task \(i\in\mathbb{T}\) is calculated in Algorithm 1, image size \(\zeta_{i}\), task size \(\zeta_{i}\), task life \(\rho_{i}\) and their corresponding coefficients \(\omega_{1}\), \(\omega_{2}\), and \(\omega_{3}\) should also be set properly according to Equation (2). Intuitively, tasks with more resource requirements have a large size of \(\zeta_{i}\) and \(\mathfrak{k}_{i}\). In our experiments, \(\zeta_{i}\) and \(\mathfrak{k}_{i}\) were set at \(C_{1}\cdot\psi_{i}\) and \(C_{2}\cdot\psi_{i}\), respectively, where \(\psi_{i}\) is the required memory size of task \(i\) and \(C_{1}\) and \(C_{2}\) are two constants sampled from \(N(1,5)\) and \(N(0.1,1)\), respectively. Value of \(\rho_{i}\) was set for task \(i\) during iterations. Values of \(\omega_{1}\), \(\omega_{2}\) and \(\omega_{3}\) were all set at 0.1. Table 2 shows the detailed parameter settings. \begin{table}
\begin{tabular}{c c c c} \hline \hline \multirow{2}{*}{**No. of Hosts**} & \multicolumn{3}{c}{**No. of Tasks**} \\ \cline{2-4}  & **Low Load** & **Medium Load** & **High Load** \\ \hline
1000 & 1600 & 3200 & 4300 \\ \hline
13,654 & 22,000 & 44,000 & 58,000 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Workload settings for the experiments. To evaluate the scheduling performance of Pool, status of some tasks and hosts is modified. In our experiments, the percentage of changed tasks and hosts increased from 1% to 100% with step 1%. For a certain number of changed tasks and hosts, three operations were adopted sequentially, namely adding, deleting and changing tasks and hosts. In the third operation, besides the resource requirements of tasks and supplies of hosts were changed, communication patterns of tasks were also modified. ### Experiment Environment

Our experiments were implemented and analysed on Ubuntu 20.04 LTS in a computer with Intel(r) i7-7700 8 core CPU (3.60 GHz), and 16 GB RAM. Scheduler Pool was written in C++ and a open source MCMF algorithm library called _MCFClass_[45] was adopted to obtain the optimal flow. All our experiments were carried out in a simulation environment. ### Time Performance

Considering the frequent changes of the status of tasks and hosts, scheduler should give the approximate optimal assignment decisions as soon as possible. Thus, time performance is an important evaluation metric. In each time step, two procedures are required before obtaining the assignments, namely solving the new MCMF problem and extracting assignments from the generated optimal flow. In this part, runtime consumed in both the procedures is discussed. #### 5.3.1 Time in Solving MCMF Problem

Figure 5 depicts the runtime of solving MCMF problems using NS when the numbers of hosts were set at 1000 and 13,654 in different load levels. Figure 5 presents the experiment results when setting the number of hosts at 1000. When solving MCMF problems incrementally, runtime of NS is proportional to the percentage of changed tasks and hosts in all three load levels. The larger the load level, the bigger the growth rate of runtime. This is obvious since more tasks are changed for a certain percentage. On the contrary, runtime of solving MCMF problems from draft increases very slightly, which can be attributed to the polynomial time complexity of NS. At the same time, its variance is very big especially in high load level (4300 tasks). The reason may be that the initial feasible tree adopted in NS algorithm has a great impact on the successive iterative efficiency. Similar conclusions can be obtained when setting the number of hosts at 13,654 in Figure 5.