# 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
In this regard, with \(N\) being the total number of configured channels (total GPS and Galileo), the GNSS processing is allocated on the four cores as follows:  
* Core 0 is scheduled for the execution of the main thread, in charge of performing the main function, the tracking of \(N_{0}=\left\lfloor\frac{N}{3}\right\rfloor\) number of channels and the PVT computation. * Core 1 is devoted to the FE thread, in charge of managing the FE and USB only. * Core 2 is allocated to a channel thread, dedicated to tracking \(N_{2}=\left\lceil\frac{N}{3}\right\rceil\) number of channels. * Core 3 is allocated to another channel thread, dedicated to acquiring 1 channel and tracking \(N_{3}=N-N_{0}-N_{2}\) number of channels. It is also in charge of executing the TESLA key verification thread, created only for the first received TESLA key in case the distance in the chain from the root key is above 700 steps. The interested reader can refer to [20] for details about the multi-thread structure of eNGene. The above-described channels-cores mapping rule is totally empirical, and for the \begin{table}
\begin{tabular}{c c c c} \hline \hline \multirow{2}{*}{**Platform**} & \multicolumn{2}{c}{**CPU Usage**} & \multicolumn{1}{c}{**RAM Usage**} \\ \cline{2-4}  & **Average (\%)** & **Maximum (\%)** & **Maximum (MiB)** \\ \hline
1 & 39.7 & 44.0 & 24.3 \\
2 & 266.9 & 297.0 & 148.0 \\
3 & 173.7 & 204.3 & 151.0 \\
4 & 244.0 & 276.4 & 27.5 \\ \hline \hline \end{tabular}
\end{table} 
Table 11: CPU and RAM usage summary. Figure 9: Time evolution of the cores’ usage of eNGene receiver on ODROID-X2 (a), Raspberry Pi4 (b) and ODROID-C4 (c) platforms for 12 satellites, i.e., 6 GPS and 6 Galileo, simultaneously tracked. considered test setup where \(N=12\), cores 0, 2 and 3 elaborate \(N_{0}=N_{2}=N_{3}=4\) channels each. With the acquisition being the heaviest function from a computational point of view, as already said, only one channel is acquired at a time and always allocated on a specific core, i.e., 3. Looking at Figure 9, as expected the core 0 (green plot with \"plus\" markers) is the one showing the highest CPU usage, since it performs PVT computation in addition to the tracking of four channels, whereas cores 2 (light blue plot with \"circle\" markers) and 3 (purple plot with \"square\" markers) have similar loads, being dedicated to the tracking of the same number of channels. The slight increase of the core 3 load, particularly visible in the first part of the test in Figure 9a,b, is justified by the acquisition stage. Once all channels have been successfully acquired and are in the tracking loop, no additional channel is scheduled for acquisition, unless a tracking lost occurs. Finally, the core 1 load roughly stands at around 20% for both ODROID-X2 (Figure 9a) and Raspberry Pi4 (Figure 9b), whereas it is much higher, roughly around 65% for ODROID-C4 (Figure 9c). Again, a clear difference of the 32 bit and 64 bit OS behavior is evident as for the RAM usage. Now, eNGene makes use of the libusb library to manage the USB stream of raw samples from the FE; thus such behavior could be likely due to a different libusb library implementation and handling from the OS side. It is worth noticing that, although specifically and properly setting both thread-cores mapping and the threads priority with root permissions at the receiver power on, the developer has not full control of the OS task scheduler. This probably suggests implementing a real-time core load check, thereby changing dynamically the allocation of the tasks. Indeed, while the load among cores looks more balanced on ODROID-C4, it seems core 1 could bear additional tasks on ODROID-X2 and Raspberry Pi4. The requirement for a better balance can also be deduced looking at the results in Figure 10a, where the number of channels has been increased to 16, i.e., 10 GPS and 6 Galileo, while keeping the same cores allocation (five channels on cores 0 and 3, and six on core 2).