# Elastic Computing in the Fog on Internet of Things to Improve the Performance of Low Cost Nodes
## 5 Test Bed for Soundscape Monitoring and Its Performance Analysis
### Performance Evaluation of the Cluster in the Fog
The slaves have memory enough to keep the audio chunks in RAM. The global queue will grow as \(\lambda-c\cdot\mu\) and it will be distributed among the slaves. We test \(\lambda\) in steps of 0.1 chunks/second from values greater than \(c\cdot\mu\), with a maximum of 10 chunks/second. In all the scenarios, we sent the same workload, 100 audio chunks at the given rate several times till we met the confidence interval. Notice that we always create congestion at each slave once its cores are busy with their first audio chunk. The idea is to observe how the system behaves under congestion. Additionally, it must be stressed that the client is configured without time outs in the application (REST-API) because it would produce duplicated chunks. Then, the cluster is behaving as a conservative system. On the other hand, without congestion, the input workload would be lower than the output workload processed, avoiding any queue. In the scenario without congestion, \(\lambda<c\cdot\mu\), we tested \(\lambda\) from 0.1 chunks/second till \(c\cdot\mu\). Figure 4a-c shows the input workload (\(\lambda\) in audio chunks per second) compared to throughput (audio chunks processed (or jobs) per second), comparing Kubernetes to Swarm with _Pods_/slave and different slaves ((Figure 4a) one slave, (Figure 4b) two slaves, and (Figure 4c) three slaves). In this case, in all the scenarios when the total number of _Pods_ were busy, as could be expected, the scenario became congested, although the systems showed a constant throughput since each node kept their tasks in RAM in a FIFO fashion. It must be noticed that Swarm shows a greater throughput according to the previous results, around 10% more, and this enhancement increases with the number of _Pods_. In addition, we compare in Figure 5a-c, the average resource uses in terms of percentage of CPU, percentage of RAM memory, and CPU temperature, respectively. In terms of percentage of CPU (Figure 5a) both COPs have a similar behavior, increasing with the number of _Pods_. They show a minimum of 35% approximately, adding 20% approximately when each core is activated. In theory, because the RPi has four cores, every time a core is completely busy the CPU will increase 25%. From these results, Swarm shows a slightly greater use of CPU, because the cores have less idle time providing higher utilization. The maximum was reached by Swarm with a 95% (with four cores working) and Kuberentes had 10% less. Notice that we should take into account the initial resource use without any service (by default), with both COPs.In this case, Kubernetes used in the master, 17% CPU and 74% RAM, and in the slaves, 6% CPU and 33% RAM. In the same conditions, Swarm used in the master, 0.7% CPU and 22.48% RAM, and in the slaves, 0.53% CPU and 16.16% RAM. In terms of percentage of RAM memory (Figure 5b), things are different because Kubernetes usually uses 15% approximately more memory. In part, this is due to a lower throughput, as we saw in Figure 4a-c, and then it has to keep the audio chunks in memory in the meantime. Finally, for the CPU temperature (Figure 5c), according to the CPU use, Swarm gets between 2 and 3 degrees higher than Kubernetes in all the combinations. Figure 4: Throughput comparing Kubernetes vs Swarm with different slaves ((**a**) 1, (**b**) 2 and (**c**) 3) and _Pods_/slave. Figure 5: Resource use comparing Kubernetes to Swarm with different slaves and _Pods_/slaves: (**a**) percentage of CPU, (**b**) percentage of RAM memory, and (**c**) temperature.