# Computational Load Analysis of a Galileo OSNMA-Read Receiver for ARM-Based Embedded Platforms +
## 5 Computational Burden Analysis of the Complete Receiver
### Real-Time Processor Load Analysis  
The profiling presented in the previous subsection provides an estimation of the computational weight of each software function, allowing to identify any possible bottleneck that can then be addressed by the developer to improve performance. Anyway, a software profiling alone cannot show a whole and final picture of the real time performance. Indeed, the total receiver computational load is directly dependent on the number of satellite signals to be simultaneously elaborated. Thus, an analysis of the processor load performed on the application in real-time is required to evaluate the limit each platform is able to reach. For this test campaign, the receiver was directly fed by the output of the RF FE, thereby processing on the fly the generated raw digital samples. \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & & **Platform 2** & **Platform 3** & **Platform 4** \\ \hline \multirow{5}{*}{\(\text{CO}^{\text{\text{\text{\text{\text{\text{\text{\text{\text{\text{ \text{\text{\text{\  
Figure 8 reports the CPU and RAM usage of the software receiver, running in real-time on all the four platforms for 12 satellites, i.e., six GPS and six Galileo, simultaneously tracked, across 10 min of total execution time. The results were obtained using the Linux utility top. It is worth noticing that eNGene features a multi-thread structure, exploiting all available cores hosted by the embedded platforms, i.e., four, as shown in Table 2, implying a CPU usage ranging from 0% up to 400% in Figure 8. On the contrary, running on a standard PC, NGene is a single-core process, with no need to specifically split the processing on all the eight available cores. Results in Figure 8 are in line with the profiling results described in the previous subsection. Indeed, with a usage less than 50% of the total Intel CPU power, the standard PC (see the light blue plot) exhibits performance far superior than any other platforms. Among the embedded boards, ODROID-X2 (red plot) shows the worst result, as expected, and Raspberry Pi4 (yellow plot) overtakes ODROID-C4. The RAM usage, expressed in MiB unit (1 MiB = 2\({}^{20}\) bytes), deserves a separate discussion. The presence of two main clusters can be clearly noticed in Figure 8: a former around 25 MiB for the standard PC and ODROID-C4 (both with a 64-bits OS) and a latter around 150 MiB for the remaining boards (both with a 32-bit OS). Such difference is not negligible and requires further investigations. In this regard, it is worth noticing that top does not report only the memory statically or dynamically allocated by the program, which is the same on all the considered boards, but the so-called resident memory or resident RAM, defined as the non-swapped physical memory a task is currently using, including all stack and heap memory, and memory and pages actually in memory from shared libraries. According to this, it is clear how the RAM usage strictly depends on the OS and is not in the direct control of the developer. Anyway, as a general observation, and considering the increasing size of available RAM abort the modern processors, the observed values cannot be considered critical. Table 11 summarizes the CPU and RAM usage results, showing the average and maximum CPU load, and the maximum RAM usage. The Raspberry Pi4 is the one getting the best results among the embedded boards, showing 28% and 26% improvements with respect to ODROID-C4 in terms of average and peak CPU usages respectively, thus being perfectly in line with the results shown in Figure 7. On the other hand, ODROID-C4 exhibits a much more efficient RAM usage, but, as already said, this is not a critical indicator for the real-time execution. Figure 8: Time evolution of the CPU (**a**) and RAM (**b**) usage of eNGene receiver on the four platforms for 12 satellites, i.e., 6 GPS and 6 Galileo, simultaneously tracked. Now, focusing on the embedded boards only, Figure 9 shows how the CPU usage reported in Figure 8 distributes over each single core.