## 4 Evaluation
### Discussion  
Real time data capture and edge processing present many challenges in terms of managing compute performance and overall data transfer on device. Existing software frameworks in this domain are often designed with assumptions that data transfer overhead, as a result of serialisation, is negligible compared to the anticipated computational load or are designed to be used on large compute clusters without the computational or concurrency constraints inherent in lower power edge sensors. In this section, we have highlighted that the REIP SDK can handle complex data processing pipelines that outperform other approaches, such as Python's multiprocessing or other frameworks (e.g., Apache Ray). An important and often overlooked aspect of data processing pipelines is the moving of data between processing blocks. Serialisation of data so that it can be exchanged between these blocks can impose significant overhead to complex pipelines, especially when these data are large in size. REIP's hybrid approach to serialisation shows comparable or better performance than other frameworks in the complex video processing pipelines presented. The ability to define a \"small\", \"medium\", and \"large\" throughput flags (defined in Section 4.1.2) when establishing block connections provides a way to select the optimal serialisation technique applied for the scale of data being passed between these blocks. When implementing an audio-based processing pipeline on various embedded compute platforms typically used in sensor networks, service times stayed below 10% when using the REIP SDK. The consistency of these service times is worth noting, as they stay relatively steady between hardware platforms, which suggests that the serialisation ap \begin{table}
\begin{tabular}{c c c c c c c c c c c c} \hline \hline \multirow{2}{*}{**Block**} & \multicolumn{3}{c}{**Raspberry Pi 4B**} & \multicolumn{3}{c}{**Jetson Nano**} & \multicolumn{3}{c}{**Jetson TX2**} & \multicolumn{3}{c}{**Jetson AGX Xavier**} \\ \cline{2-13}  & **Process** & **Wait** & **Service** & **Process** & **Wait** & **Service** & **Process** & **Wait** & **Service** & **Process** & **Wait** & **Service** \\ \hline Microphone & 0.39\% & 92.9\% & 6.68\% & 0.19\% & 92.4\% & 7.28\% & 0.10\% & 93.1\% & 6.72\% & 0.19\% & 92.2\% & 7.33\% \\ Machine Learning & 42.1\% & 50.4\% & 5.12\% & 30.0\% & 61.7\% & 7.73\% & 37.7\% & 56.4\% & 5.31\% & 12.2\% & 78.3\% & 8.75\% \\ SPL Computation & 4.74\% & 88.5\% & 6.75\% & 2.58\% & 90.0\% & 7.36\% & 2.01\% & 91.1\% & 6.84\% & 2.40\% & 90.0\% & 7.53\% \\ Audio Writer & 1.82\% & 91.6\% & 6.58\% & 0.41\% & 92.4\% & 7.20\% & 0.09\% & 93.3\% & 6.63\% & 0.14\% & 92.6\% & 7.25\% \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Time spent by different blocks in the audio processing pipeline (Figure 3(b)) performing data processing, idle waiting, and servicing the data between blocks. Comparison is given for different embedded platforms ranging from a low-budget Raspberry-Pi 4B to the high-performance NVIDIA Jetson AGX Xavier. The service times remain well under 10% for each platform, which indicates negligible performance overhead introduced by the REIP SDK. No dropped buffers were detected. proach of the REIP SDK is agnostic of the platform it is running on. These service times are likely driven mainly by the memory architecture of the device which impacts serialisation, rather than its computational power. We consider the service overhead of the REIP SDK in these examples to have a minimal impact on overall performance and generalise well to different hardware platforms; however, further work is needed to compare the service times of other frameworks. In REIP, we are targeting the design, and more specifically in this paper, the code implementation and computational challenges that often arise during the design, development and deployment of individual sensors as well as sensor networks.