# Achieving Low Latency Communications in Smart Industrial Networks with Programmable Data Planes
## 6 Results and Discussion  
In this section, the results of previously presented experiments are shown and analyzed. Firstly, when it comes to the first experiment involving tests **1.1** and **1.2**, Figure 9a shows response time measurement results. The abscissa axis represents the two evaluated scenarios (scenario A in the left and scenario B in the right), while in the ordinate axis, the actual response time values are provided. The boxplot has been calculated with 98 percentile and shows the median (horizontal line), the mean (x), the box (top limit 75 percentile and bottom limit 25 percentile), \"whiskers\" (that contain the 98% of results), and outliers (circles, the 2% that is left of results). Figure 9b shows the same response time measurements in a histogram format. As the figure shows, the cloud case has a mean latency of 61.992 ms, along with a noteworthy variability that can be seen due to a wide distribution of results. However, the edge broker case has a mean of 16.464 ms and high consistency in the majority of results, comprising the 98% of them in a 3 milliseconds margin. The difference between both cases attends the expected behavior, being 74% lower in the case of scenario B (the edge broker and the INC with P4) than scenario A (the regular cloud communication). As it is logical, the communication with the cloud that crosses the ISP network is slower and more variable. Still, the difference also includes the extra processing that the cloud broker has to do in order to check if the sensor value exceeds the threshold. In the case of the edge broker, that processing is done in the SmartNIC with P4 code, but not for the cloud. To check the contribution of that extra processing, a ping has been performed against the cloud broker with the same packet length as MQTT publish messages to measure the RTT without that additional processing. Figure 10 shows the results of the latency taken with the ping tool from the publisher to the cloud broker. The mean time of the RTT is 25 ms, so it is safe to say that MQTT processing in the cloud broker introduces a delay of 40 ms. It is evident that additional processing in the cloud contributes to increasing the delay of the communication compared to the edge. When it comes to the second experiment involving the processing delay introduced by the INC application, Figure 11a,b show the comparison between communications with and without the SmartNIC, towards the cloud broker (left-hand side, **tests 2.1 and 2.2**, in that order) and towards the edge broker (right-hand side, **tests 2.3 and 2.4**, in that order). When it comes to the first and second tests, Figure 11a, the disparity of both cases is almost indistinguishable. On the other hand, Figure 11b shows that direct processing has a slightly lower delay, a difference of only 0.501 ms between both cases (mean times of 14.607 ms with SmartNIC and 14.107 ms without SmartNIC). These results demonstrate that processing in the SmartNIC is efficient enough to prove its validity. Figure 9: Latency measurement experiment for scenario A (**test 1.1**, regular cloud broker) and scenario B (**test 1.2**, alarm edge broker). Finally, throughput results are analyzed in the third experiment, using the case of 5% of values being generated above the threshold (**test 3.2**) to show the procedure of throughput calculation. In the case where the processing is performed at the cloud, as no preprocessing is performed at the SmartNIC, all the packets must be sent to the cloud in order to compare their conveyed value with the predefined threshold. With 5% of conveyed values being above the threshold, a total of 4082 MQTT packets have been sent, 1001 of which have \"test\" topic and 58 \"alarm\" topic (these are the alarm response messages  
Figure 11: Network delay with and without SmartNIC processing. (**a**) Communications with the cloud broker. (**b**) Communications with the edge broker. Figure 10: Histogram of latency measurements of ICMP Echo requests from sensor to the cloud broker. generated by the cloud broker).