## 5 The COGNIFOG Project
### Technology Demonstrator
Exploring this scenario, we have run a simple experiment to measure the performance of our test application, identify when constraints are not met, and trigger runtime reconfiguration. The experiment uses real-time monitoring of MQTT topics associated with the object detectors that are processing real-time camera feeds. Timestamps are used to determine the periodicity of messages and message size used to compute bandwidth costs. In Figure 5, the bar graph shows a snapshot of the measured period for the object detection of all camera frames. The graph highlights eleven frames with periods exceeding the defined 2s threshold (red line), shown as blue bars and labelled 'period before (ms)'. This observation indicates potential performance bottlenecks. To address this, the options are to (a) migrate object detectors to a more powerful machine or (b) scale the number of object detectors horizontally. Given that the Quick Start environment only instantiates homogeneous machine types (i.e., only CPUs and no GPUs), horizontal scaling was chosen. COGNIFOG is triggered to re-evaluate resources available and system-wide application constraints and chooses to deploy more object detectors within the working cluster. Since more pods are deployed to manage the camera images, the average response latency for identifying the objects is reduced. Once reconfiguration has taken place, ongoing monitoring shows that the timing constraint violations have been resolved for object messages--this is shown in the bar graph as orange bars labelled 'period after (ms)' redeployment. The bar graph shows the percentage reduction in the message period for object detection in all camera frames after horizontal scaling has been applied. The graph illustrates the improvement ranges from 37% to over 50%. This measurement demonstrates that adding more pods effectively reduces the response latency of the system for all camera feeds. The role of COGNIFOG is to verify if the latencies meet application constraints defined by the user and if not, a rescheduling action is applied. In QuickStart, we can only scale up the number of pods (due to homogeneous VMs) but in the project's use cases, the intent is to deploy the workload across the full CEI continuum. The findings from the previous study were then validated across multiple runs, with each run corresponding to 10 min of data acquisition. The chart below (Figure 6) presents a  
Figure 5: Performance of technology demonstrator application with 3 object detectors. comparison of average object detection periods (in milliseconds) across multiple cameras, measured before and after scaling more pods for object detection computation. Each box plot represents the distribution of detection periods for a specific camera. The 'period before (ms)' values correspond to measurements taken prior to the application of horizontal scaling, while the 'period after (ms)' values reflect performance following the new deployment. The results show a significant improvement across all cameras, with detection periods consistently decreasing after the enhancement. The outlier visible in the 'period before (ms)' section represents an unusually high object detection period (above 3 s). This event can be explained by network latencies and/or processing bottlenecks but the redeployment with more pods helped eliminate such extreme delays. Moreover, the variability in detection times is notably reduced, indicating not only faster but also more stable performance. This indicates the performance improvement, attributed to horizontal scaling. In summary, our initial tests using the technology demonstrator have shown that two key requirements, automatic deployment and dynamic reconfiguration, have been achieved using the COGNIFOG platform allowing developers to build applications that exploit the CEI continuum. We are currently finalising the Quick Start application framework with the  
Figure 6: Object detection periods before and after scaling using COGNIFOG.