## 4 SACDTO Strategy
### SACDTO Implementation
\begin{table}
\begin{tabular}{c c} \hline \hline
**Parameters** & **Value** \\ \hline Replay memory size & 5000 \\ Optimizer & Adam \\ Learning rate for Actor and Critic networks & 0.001 \\ Minibatch size & 128 \\ Discounted factor for reward & 0.99 \\ Delayed update factor & 0.995 \\ Initial value of temperature parameter & 0.2 \\ The learning rate of temperature parameter & 0.001 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Parameters for algorithm implementation. Figure 2: Convergence Analysis of Graph. energy consumption generated by the local execution of all computing tasks will increase significantly, while the cost generated by the solution after the offloading decision increases relatively slowly. Therefore, the ratio of the two will be different, and the solution with good effect will have relatively higher TERS. Figures 4 and 5 respectively show the service latency and energy consumption of the five offloading schemes with an increasing number of tasks. Obviously, with the increase in the number of tasks, the total energy consumption and delay of these five strategies also increase. The latency and energy consumption of all locally executed computing tasks are increasing significantly, while the growth curves of service latency and energy consumption of the three DRL-based offloading strategies are relatively flat, which indicates that the above strategies have optimized the service latency and energy consumption of the system. In particular, SACDTO has an average reduction of 1.6%, 42.13%, 47.73%, and 62.19% in service latency and 78.49%, 6.7%, 89.12%, and 94.93% in energy consumption compared with PPOTO, D3 QNTO, RTO, and ALOC, respectively. This shows that with the increase in the number of tasks, SACDTO learns a better offloading strategy, which can effectively reduce the delay and energy consumption. Figure 4: The Effect of Number of Tasks on Delay. Figure 3: The Effect of Number of Devices on Delay. Figure 6 shows the relationship between CCR and TERS. CCR is the ratio between communication cost and computation cost. The smaller the value, the more intensive the computation task. In this experiment, the CCR is set between 0.2 and 0.6. We noticed that the more intensive the computation task, the higher the optimization ratio of SACDTO and TPOTO, while D3 QNTO and RTO fluctuated greatly without obvious regularity. This is because the higher the cost of communication and the more intensive the task, the greater the latency and energy consumption of local computing. The better the offloading strategy, the more significant the cost reduction and, therefore, the greater the percentage reduction relative to the cost of local computing. In addition, the proposed SACDTO outperforms the other three strategies in the CCR of this value range, being 6.41%, 41.2% and 50.8% higher than TPOTO, D3 QNTO, and RTO, respectively. ## 6 Conclusions and Future Work

In this paper, we investigate the offloading problem with dependent tasks, aiming to jointly optimize the delay and energy consumption in multi-server and multi-device scenarios and effectively improve the QoS. To cope with the dynamic scenario of MEC, we propose an edge-cloud collaborative MEC architecture, which models the optimization problem as an MDP. We use DAG to represent dependent tasks, embed DRL training in the MEC system, and use a neural network to approximate the policy function and value

Figure 5: The Effect of Number of Tasks on Energy Consumption. Figure 6: The Effect of CCR on TERS. function of MDP. This paper proposes an intelligent task offloading scheme SACDTO, which can offload each task to the corresponding MEC server through centralized control, greatly reducing the service delay and terminal energy consumption. Experimental results show that the algorithm converges quickly and stably, and has strong adaptability in different MEC scenarios. The optimization effect of the algorithm is better than ALOC, RTO, D3 QNTO, and PPOTO. In the future, we plan to use multi-agent reinforcement learning to share the common resource pool.