# GASP: Genetic Algorithms for Service Placement in Fog Computing Systems
## 4 Experimental Results
### Experimental Testbed  
To evaluate the viability of our proposal, we consider a fog scenario characterized by (1) a significant number of sensors; (2) a set of fog nodes, with limited computational power that aggregate and filter the data from the sensors; and (3) a cloud data center that collects the information processed by the fog nodes. Our testbed scenario is based on a smart city whose topology is based on a real Italian city (Modena) with a population in the order of 180,000 inhabitants. Our reference use case is a traffic monitoring application. The sensors, fog nodes, and cloud data center are shown in Figure 4 to represent the smart city scenario. To gather data concerning traffic-related measures, such as the number of cars passing in each street (with their speed), we place wireless sensors on the main streets of the city. To model the application, we referred to the Trafair Project [9], currently involving the city of Modena considered for the topology model. The sensor map in Figure 4 is created starting from the georeferenced list of the streets of the cities characterized by higher volumes of traffic: we assume to have one sensor for each one of these streets. Furthermore, we selected a group of six buildings that host offices of the municipality and are interconnected with a high speed metropolitan area network: each one of these buildings is assumed to host a fog node. The final scenario is composed of a 89 sensors and six fog nodes. The interconnection between fog nodes and sensors is characterized by a delay that we model using the euclidean distance between the nodes. The average delay is in the order of 10 ms, which is consistent with a geographic network. Finally, we assume to have only one cloud data center, which is located where the Modena municipality data center actually is, and is connected to the fog nodes through low latency links not considered in the optimization model. Concerning the traffic model, we describe each scenario based on two metrics. The first metric is the average load of the system, \(\rho\), and the other parameter, \(\delta\mu\), represents the ratio between the average network delay (\(\delta\)) and the average service time (\(1/\mu\)). Specifically, we define the two parameters as  
\[\rho =\frac{\sum_{i\in\mathcal{S}}\lambda_{i}}{\sum_{j\in\mathcal{F}} \mu_{j}} \tag{6}\] \[\delta\mu =\frac{\sum_{i\in\mathcal{S}}\sum_{j\in\mathcal{F}}\delta_{ij}}{| \mathcal{F}||\mathcal{S}|}\cdot\frac{\sum_{j\in\mathcal{F}}\mu_{j}}{|\mathcal{ F}|} \tag{7}\]  
Figure 4: Smart city scenario. In our experiments, we consider several scenarios, corresponding to different combinations of these parameters, to analyze the performance of the GA-based solution for the sensor mapping problem. For example, a scenario where \(\rho=0.8\) and \(\delta\mu=0.01\) (corresponding to the bottom right corner of Figure 5) represents a case where the network delay is much lower than the average job service time, and the processing demand on the system is high. This means that the scenario is CPU-bound because managing the computational requests is likely to be the main driver to optimize the objective function. On the other hand, a scenario where \(\rho=0.2\) and \(\delta\mu=1\) (top left corner of Figure 5) is a scenario characterized by a low workload intensity and a network delay comparable with service time of a job, where it becomes important to optimize also the network contribution to the objective function. Throughout our experiments, we first consider the implementation of the model discussed in Section 2, using the AMPL language [21] and KNITRO [15] as the solver. Due to the nature of the problem, we were not able to let the solver run until the convergence. Instead, we placed a walltime limit of 120 minutes, with a 16-core CPU and 16 concurrent threads. We compare the results of this solver with the GA-based implementation, that uses the Distributed Evolutionary Algorithms in Python (DEAP) framework [19].