# Distributed Uniform Streaming Framework:
## 5 Experiments
### Use Case 2: Fog Computing  
The second use case covers the optimization problem of multiple edge devices that can run multiple application components. Figure 5 shows the configuration of this experiment. The two sensors on the left will send data to the processor component in the middle. The processed data is then sent to the actuator on the right, which performs an action with the data. An average of every 3000 samples of the first sensor is also sent to the cloud though, as shown in the top half of the figure. The Sensor 1 and actuator components are executed on a Raspberry Pi 3 B+ with only a single core enabled. The Sensor 2 component is placed on a different Raspberry Pi 3 B+ with all its four cores enabled. The cloud node runs on an Intel i7-7700 HQ processor.  
As a reference, we locked the software components to fixed devices as a reference for the performance. The results without optimizations are shown in the first four rows of Table 4. We observe  
\begin{table}
\begin{tabular}{l l l l l l} \hline \hline
**Managed by** & **Filter before** & **Filter after** & **CPU Usage of** & **Messages** & **Total Network** \\
**DUST** & **Migration** & **Migration** & **Sensor/Cloud (\%)** & **Received** & **Usage (MB)** \\ \hline \hline \(\mathcal{K}\) & Sensor & Sensor & 29.2/1.1 & 44,420 & **5.20** \\ \(\mathcal{K}\) & Cloud & Cloud & 16.3/2.0 & 44,560 & **7.44** \\ \hline \hline \(\checkmark\) & Sensor & Sensor & 29.2/1.5 & 44,460 & **5.48** \\ \(\checkmark\) & Cloud & Sensor & 29.2/1.9 & 43,940 & **5.63** \\ \hline \hline \end{tabular}
\end{table}
Table 2: Network optimization of use case 1.  
Figure 5: The streaming configuration from sensors to the actuator. The events from sensor 1 are also averaged over time and send to the cloud.  
\begin{table}
\begin{tabular}{l l l l l l} \hline \hline
**Managed by** & **Filter before** & **Filter after** & **CPU Usage of** & **Messages** & **Total Network** \\
**DUST** & **Migration** & **Migration** & **Sensor/Cloud (\%)** & **Received** & **Usage (MB)** \\ \hline \hline \(\mathcal{K}\) & Sensor & Sensor & 89.1 \({}^{a}\)/2.6 & **192,040** & 12.81 \\ \(\mathcal{K}\) & Cloud & Cloud & 89.7 \({}^{a}\)/13.2 & **409,960** & 43.87 \\ \hline \hline \(\checkmark\) & Sensor & Cloud & 89.3 \({}^{d}\)/5.3 & **326,340** & 34.28 \\ \(\checkmark\) & Cloud & Cloud & 86.9 \({}^{a}\)/5.8 & **380,060** & 40.90 \\ \hline \hline \end{tabular} \({}^{a}\) The remaining CPU cycles are used by kernel.  
\end{table}
Table 3: CPU optimization of use case 1.  
a high CPU usage on the actuator node while there are still computational resources available on other nodes. Additionally, the network load of the Cloud node is very high which we ultimately want to avoid as this connection often is more expensive. When the same configuration is managed by the DUST framework, we notice that the DUST Coordinators place the Processor and Average Application component to the actuator node as shown in the last four rows of Table 4. The actuator node has more computational resources. By migrating the blocks to the actuator node, the network usage of the cloud node is significantly reduced, and the CPU load of the actuator and Sensor 1 node is minimized.