## 6 Evaluation
### Comparison with Manual Sample Construction Methods  
At present, the major traffic sample construction in the industry is still achieved by manual methods, which have many defects. We compare the A3C system with the manual sample construction method by experiments in Windows. Firstly, we conducted fifty sample purity experiments in environment P and calculated the ratio of interfering packets after filtering out DNS packets. We collected the target app, Chrome, for nearly 312 seconds each epoch. In manual construction, Wireshark was used to collect all traffic of the network adapter. A3C synchronously collected the traffic of the network adapter and filtered out the pure Chrome traffic. We selected three typical experimental results in environment P, as shown in Table 6.  
Experiments show that the proportion of interfering traffic increases with the number of packets captured. The main reason may be that the packet density of the traffic generated by the OS is higher than the average application traffic. At the same time, to exclude the characteristics of Environment P's own Windows operating system configuration, we re-conducted 69 experiments under another Windows device with similar performance to make statistics on the relationship between toxic ratio changes. We drew the experimental results as a dot-line graph, as shown in Figure 11. \begin{table}
\begin{tabular}{c c c c c} \hline \hline \multirow{2}{*}{**Index**} & \multicolumn{2}{c}{**Captured Pkts**} & \multirow{2}{*}{**Irrelevance**} & \multirow{2}{*}{**Toxic Ratio**} \\ \cline{2-2} \cline{4-5}  & **A3C** & & & \\ \hline
1 & 69,764 & 70,383 & 619 & 0.8\% \\
2 & 59,117 & 59,490 & 373 & 0.6\% \\
3 & 70,130 & 70,769 & 639 & 0.9\% \\ \hline \hline \end{tabular}
\end{table} 
Table 6: A3C vs. manual method in Windows (environment P). \begin{table}
\begin{tabular}{c c c} \hline \hline \multicolumn{1}{c}{**Estimator**} & **Wireshark** & **PacketCapture** \\ \hline Packet Count & 2254 & 815 (reassembled) \\ Duration (s) & 24.830 & 25.112 \\ Mean Packet Size & 640 & 1662 \\ Captured Bytes & 1,442,474 & 1,354,368 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Quantitative comparison of Packet Capture to Wireshark. \begin{table}
\begin{tabular}{c c c} \hline \hline \multicolumn{1}{c}{**Estimator**} & **Wireshark** & **A3C-Android** \\ \hline Packet Count & 1480 & 1491 \\ Duration (s) & 23.423 & 22.418 \\ Mean Packet Size (bytes) & 613 & 562 \\ Captured Bytes & 906,709 & 837,843 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Quantitative comparison of A3C-Android to Wireshark. The experiment lasted longer, using a script to open ten web pages on the device in sequence. In order to better reflect the distribution relationship of the toxic ratio, our results are ranked from low to high. It can be found that some of the results are consistent with the representative results in the last experiment. The toxic ratio in most of the results was unexpectedly high. The main reason is that the experiment period is very long, in which the Windows operating system may download some Metro application data and update weather and news spontaneously, which will lead to a significant increase in the toxic ratio. In the latter cases, the extremely high level of toxic radio is due to the system update content downloaded by the Windows operating system, which will transmit a large amount of data in a short time, resulting in a sharp increase in the toxic ratio. Therefore, the blanket sample capture of the manual method is not desirable. There will be some confusion packets and cause devastating sample contamination through system updates at unpredictable times. Furthermore, we carried out an experiment on the situation of sample construction for multiple applications running simultaneously in environment P. We used Netease Cloud Music, Chrome, WeChat, and QQ concurrently in an experiment. A3C can clearly distinguish the traffic generated by the four applications.