# Fog vs. Cloud Computing: Should I Stay or Should I Go? +
## 4 Analyzing Test Cases
### Deciding between Fog and Cloud Considering Execution Time  
As seen in Section 3, we only depend on the variables \(s\), \(t\), and \(f\) for our calculations, so we start by finding these values. Tables 10 and 11 in Appendix B show the values for \(t\) in milliseconds measured for each benchmark and dataset, and we use the measurement of \(s=7.3\,\mathrm{ms}\)[24] in all fog-prone test cases and \(s=0.73\,\mathrm{ms}\) for the cloud-prone ones. Having these values, we can now calculate \(C_{f0}\) and \(C_{c0}\) for the worst-case scenario from the fog point of view, that is, when \(f=1\). We are considering that \(z=65\),\(536\), so we can use Equation (5) to determine the penalty for processing a value in the fog when it would cost less to do so in the cloud (\(p\)). Given our large stream size, the penalty for each value is very small in fog-prone cases (less than \(0.001\%\)) and still relatively small in cloud-prone ones (less than \(0.01\%\)), as can be seen in Tables 10 and 11 in Appendix B. This difference is due to the fact that values for \(s\) and \(t\) are closer to each other in our cloud-prone cases. Therefore, we can look at a reasonable number of values and still have a very low increase in cost. We decided that we are willing to have a maximum increase in cost of \(0.5\%\), so that enables us to test over \(3000\) values for Outlier \(16\) and both MinMax cases, over \(900\) values for Outlier \(256\) for fog-prone cases, and ten times fewer values for cloud-prone cases (the exact numbers are also displayed in the aforementioned table). By examining the output of the benchmarks, we are able to count the values that passed the filter (\(n\)), which leads us to the \(f\) estimates, as well as the real \(f\) values for comparison. Again, all of these results are reported in Tables 10 and 11. Finally, we use the calculated \(f\) values to plot a graph similar to the one in Figure 1 for each benchmark. Like Section 4.1, here, we also used the simplified versions of Equations (1) and (2) (i.e., \(C_{f}=t+s\cdot f\) and \(C_{c}=s\)). The result is illustrated in Figure 10. The continuous lines represent the tests that use the estimated values of \(f\) (Est. ), and the dashed lines represent the tests that use the real values of \(f\) (Real). The continuous thick gray line represents the case where \(C_{f}=C_{c}\), that is, a line with a slope of \(-1\). By observing the graphs, we can determine that most of the lines are below the \(C_{f}=C_{c}\) threshold for fog-prone cases and above it for cloud-prone cases, as expected. As discussed in Section 3, the lines below the threshold mean that it is more profitable in terms of execution time to run these filters in the device that is collecting the data instead of sending the values to be processed in the cloud. On the other hand, lines above the threshold mean that, from the point of view of the device, it is more profitable to process these data on the cloud. Figure 9: Summary of the results for Outlier \(256\) cloud-prone test cases. A few notable exceptions are the MinMax benchmarks being executed on the HRelHumidity dataset in the fog-prone scenario and the MinMax \([-15,15]\) benchmark being executed on the HVisibility and HWindSpeed datasets on the cloud-prone scenario. In the first case, we see that although it was more likely that the fog would be more profitable, the lines are above the threshold,  
Figure 10: Graphs of the linear equations for each dataset and benchmark using execution time as the cost. Est., estimated. indicating that in fact the cloud is the correct choice. This can be explained by looking at the values of \(f\) for the MinMax benchmarks on the HRelHumidity dataset, which are equal to one, meaning that all values passed the filter. We can see that the cloud is more profitable every time this happens, as \(C_{f}=t+s\cdot 1\) is always larger than \(C_{c}=s\). In the second case, the lines are below the threshold, indicating that the fog is more profitable instead of the cloud.