## 4 Results  
### Tests Results  
For the tests explained in Sections 3.6 and 3.7, the average values obtained are depicted in Table 3. In this figure, we see that the payload (in terms of \"Bogo Ops\") for longer processes (10 min) is greater (and proportional to that of shorter processes (1 min)). The speed or apparent runtime (in terms of \"Bogo Ops/s\" in real time) seems to be nearly constant in both processes (the longer and shorter ones), and the runtime for the cumulative user and system time has the same behavior but on a lower scale because these do not take into account as many operations. \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Duration** & **Manager** & **Container** & & **Usr + Sys** \\
**(min)** & **Manager** & **Runtime** & **Bogo Ops** & **Bogo Ops/s** \\ \hline
10 & Docker Compose & Podman & 311,7331.0 & 5195.5 & 1300.4 \\
10 & Docker Compose & Docker Engine & 3,089,738.0 & 5149.6 & 1288.6 \\
10 & - & Docker Engine & 3,093,922.3 & 5156.5 & 1290.2 \\
10 & - & Podman & 3,050,764.7 & 5084.6 & 1272.4 \\
10 & Kubernetes & Podman & 3,027,897.3 & 5046.5 & 1279.8 \\
10 & Kubernetes & Docker Engine & 2,984,890.0 & 4974.8 & 1265.3 \\
1 & Docker Compose & Docker Engine & 308,970.3 & 5149.4 & 1288.8 \\
1 & Docker Compose & Podman & 309,507.7 & 5158.4 & 1293.0 \\
1 & - & Docker Engine & 310,324.0 & 5171.9 & 1294.4 \\
1 & - & Podman & 306,818.3 & 5113.5 & 1281.2 \\
1 & Kubernetes & Podman & 299,595.3 & 4993.2 & 1267.0 \\
1 & Kubernetes & Docker Engine & 296,143.0 & 4935.6 & 1254.3 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Averages for tests carried out with CPU using stress-ng in Section 3.6. Figure 2: System architecture for pointcloud generation using distributed computing with Raspberry Pi, Edge server and Kubernetes-orchestrated Cloud environment. For the tests described in Section 3.7, the following data are presented. Of note are the highly similar rpi, Docker and aarch64 vm measurements, demonstrating the high efficiency of containers, as well as the suitability of virtualization stacks with the appropriate extensions. On the other hand, the apparent lack of performance in Kubernetes hosted in Podman environments seems to indicate inefficiencies in the container runtime or high overheads. Finally, the extremely poor performance of the x86 virtual machine shows the difficulties in emulating legacy hardware on modern instruction set paradigms. Another interesting finding, however, is uncovered when evaluating the stress reports from the x86 host. It was discovered that completed add operations were found to be roughly equal to divide operations, as without full CPU parity, no virtual acceleration was being undertaken at all, indicating a possible area of improvement for virtualization speed when similar instructions are available. Figures 3-7 show the percentage of additional performance based on the solution that had the lowest percentage. We consider the numbers of usr + sys Bogo Ops/s and Bogo Ops/s for the task itself to have the most reliable graph possible. The purpose of these results is to identify trends, not to consider specific measures as they are not standardized. They allow us to get an idea of performance and resource management. As expected, the Kubernetes container manager solution is less effective in our scenario because we will deploy only a few containers over a short period of time. There is a difference in CPU usage performance of 5%, which can be significant in terms of time and resources. It is difficult to come to a conclusion about runtime containers here. Although the use of Docker Compose should not affect the performance results of the containers, there is a difference in the results obtained between using Docker Compose and using the runtime container alone. This difference may be due to inaccurate measurements and other factors. The measurement and explanation of these differences may be addressed in a future study. For the CPU performance graph over 10 min (see Figure 4), a similar trend is obtained.