## 6 Experimental Results and Analysis  
In this paper, the server and the agents run on Intel (R) Core (TM) i7-3770m [EMAIL_ADDRESS] GHz, 8 GB RAM and 32-bit Windows 7-based computers. Here, we select the ORL face database [47; 48] to demonstrate the effectiveness of the proposed distributed face recognition framework. The database has 400 images of 40 distinct subjects, and the image size is \(92\times 112\). In order to identify the problem of poor multi-face recognition in the case of low resolution at a long range, we increase the number of face images in the ORL database to improve the recognition ability of the model. Since the ORL face database is relatively small, we collected 178 images from seven pedestrians and added them into the ORL face database. To further enrich the image training set, we implemented multi-scale transformation of face images in the database. Here, the size of each face image is scaled by the resize function, resulting in 3,398 face images in total after six scaling transformations (\(23\times 23\), \(25\times 25\), \(46\times 46\), \(50\times 50\), \(75\times 75\), \(92\times 92\)). Some example face images collected by us are given in Figure 4.  
Four videos for testing were collected by an Axis 215 PTZ web camera with a resolution of 704 \(\times\) 576, and the frame rate of the video was five frames per second. The number of pedestrians in a video dynamically changes from one to four. During the test, we can change the amount of task at the agent side by repeatedly loading the testing videos. To facilitate the exploration for the optimal solution in the search space, the value of cross probability is set to be 0.8. By setting different mutation probabilities, the average processing time of one frame and the CPU utilization are given in Table 2.  
As shown in Table 2, when the mutation probability increases from 0.01 to 0.2, the average time for processing a frame and CPU utilization of the server decreases. As the mutation probability continues to increase, the algorithm is prevented from converging, and then the average time for processing a frame and CPU utilization of the server increases. Hence, the mutation probability is set to be 0.2 during the simulations. Figure 5 shows the iterative curve of the algorithm in load balancing. The iteration process can be terminated when the change of average fitness and maximum fitness tends to be stable. So, According to Equation (9), iteration terminates when \(\varepsilon\) is close to 1. This shows the convergence speed of the genetic algorithm in finding global optimal approximate solutions. Figure 6 shows the recognition results displayed by the agent. For example, marker \"1: Soda\" shows the order of appearance and the name of the recognized pedestrian. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Mutation Probability** & **0.01** & **0.05** & **0.1** & **0.2** & **0.4** & **0.5** \\ \hline Average time for processing one frame (s) & 0.0542 & 0.0474 & 0.0458 & 0.0423 & 0.0494 & 0.0512 \\ CPU utilization & 0.3391 & 0.3300 & 0.3255 & 0.3125 & 0.3141 & 0.3238 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: The average time for processing one frame and CPU utilization to the mutation probability. Figure 4: Our newly collected dataset. There are 3398 images of 47 subjects in the database, where 400 images come from the original ORL database, and 2998 images are expanded by us. Figure 5: Iterative curve of the algorithm. Here, in order to analyze the relationship between the processing time and the number of pedestrians in the video, we randomly select two agents for experimentation. Each agent handles one video, each of which is with a different number of pedestrians, and one agent processes only one video at a time. The processing time of different operations in each frame are given in Table 3. The average processing time on the agent side includes detection, tracking, feature extraction, and transmission time from the agent to the server.