+\smallskip
+Taken as a whole, the results illustrated in Figures~\ref{fig.results1} and ~\ref{fig.resultsN} clearly show that our proposal outperforms the Betsekas and Tsistlikis algorithm.
+These results indicate that local load balancing decisions has a significant impact on the global
+convergence time achieved by the compared strategies. This is because, upon load imbalance detection, assigning an amount of load in an unfair way between neighbors will severely increase the total number of iterations required by the algorithm before reaching the final stable distributions. The reason of the poorer performance of {\it Bertsekas and tsistsilikis} algorithm can be explained by the inconvenience of the iterative load balance policy adopted for load distribution between neighbors. Neighbors are selected in such a way that the {\it ping-pong} condition holds. Doing so, loads are not really assigned to processor neighbors which would allow them to be fairly balanced.
+
+\smallskip
+Unlike {\it Betsekas and Tsistlikis} algorithm, our approach is not really sensitive when
+we deal with realistic models of computation and communication. This is due to two main features: i) the use of "virtual load" transfers winch allows nodes to predict the load they receive in the subsequent iterations steps, ii) and the greedy neighbors selection adopted by our algorithm at each time step in the load balancing process. The involved neighbors are selected in such a way that load difference between the computational resources is minimized as low as possible.
+
+\smallskip
+Comparing the results of the extended version (with virtual load) to the results of the simple one, we observe in Figs.~\ref{fig.results1} and ~\ref{fig.resultsN} that the improved version gives the best performances. It always improves both convergence and idle times significantly in all figures. This is because, with virtual load transfers, the algorithm seeks greedily to ensure a certain degree of load balancing for processors by taking into account the information about the predictive loads not received yet. Consequently, this leads to optimize the final convergence time of the load balancing process. Similarly, the extended version achieves much better results than the simple one when considering larger platforms, as shown in Figs.~\ref{fig.results1} and ~\ref{fig.resultsN}.
+
+\smallskip
+We also find in Figs.~\ref{fig.results1} and ~\ref{fig.resultsN} that the performance difference between the improved version of our proposal and its simple version (without virtual load) increases when the CCR increases. This interesting result comes from the fact that larger CCR values reveals that we are dealing with intensive computations applications in grid platforms. Thus, in order to reduce the convergence time of the load balancing for such applications, it is important to take suitable decisions upon local load imbalance detection. That is why we added {\it virtual load} transfers scheme to the {\it best effort} strategy to perfectly balance the load of processors at each step of the load balancing process.
+
+\smallskip
+Finally, it is worthwhile noting from Figures~\ref{fig.results1} and ~\ref{fig.resultsN}, that the algorithm's convergence time increases together with network's size. We also see that the idle time increases together with the size of the network when a load is initially on a single node (Figure~\ref{fig.results1}),
+as expected. In addition, it is interesting to note that when the number of nodes increases, there is not substantial difference in the increase of the convergence time, compared to the simple version without virtual load. This is explained by the fact that the increase in the convergence time is already absorbed by the virtual load transfers between processors being in line with the network's size.
+
+%For the hypercube, in any case, the effect of the virtual load is visible. It is more visible when communications have a more important role (i.e. with the mainly communicating case).
+
+
+%Dans ce cas légère amélioration de la cvg. max. Temps moyen de cvg. amélioré,
+%mais plus de temps passé en idle, surtout quand les comms coutent cher.
+
+%\subsubsection{The \besteffort{} strategy with an initial random load
+% distribution, and larger platforms}
+
+%In
+%Mêmes conclusions pour line et hcube.
+%Sur tore, BE se fait exploser quand les comms coutent cher.
+
+%\FIXME{virer les 1024 ?}
+
+%\subsubsection{With the virtual load extension with an initial random load
+% distribution}
+
+%Soit c'est équivalent, soit on gagne -> surtout quand les comms coutent cher et
+%qu'il y a beaucoup de voisins.
+
+\subsubsection{The $k$ parameter}
+\label{results-k}
+
+As explained previously when the communication are slow the \besteffort{}
+strategy is efficient. This is due to the fact that it tries to balance the load
+fairly and consequently a significant amount of the load is transferred between
+processors. In this case, it is possible to reduce the convergence time by
+using the leveler parameter (parameter $k$). The advantage of using this
+solution is particularly efficient when the initial load is randomly distributed
+on the nodes with torus and hypercube topologies and slow communication. When
+virtual load scheme is used, the effect of this parameter is also perceptible
+with the same conditions. %However, sometimes this parameter may have a negative effect on the convergence time.
+
+
+
+
+\subsubsection{With non negative integer load values}
+In addition to the first tests devoted to the case of non negative real load values, we also carried out further experiments with integer load values to assess the performance of our proposal.
+%We also performed some experiments with integer load instead of load with real
+%number values.
+As expected,
+%In this case,
+the obtained results have globally the same behavior, that is why we decided not to show similar figures. The most
+interesting result, from our point of view, is that the virtual mode allows
+processors in a line topology to converge to the uniform load balancing state. Without
+the virtual load, most of the time, processors converge to what we call the
+``stairway effect'', that is to say that there is only a difference of at most one unit load between any pairs of neighbor nodes, i.e. the load difference between each processor and its neighbors is within one unit load (for example with 10 processors, we
+obtain 10 9 8 7 6 6 7 8 9 10 instead of 8 8 8 8 8 8 8 8 8 8).
+
+\smallskip
+To summarize and broadly speaking, the simulation results led us to show that, with few exceptions (without virtual load), our proposal is superior to the {\it Bertsekas and Tsiltsikis} algorithm in all the tested scenarios. The illustrated results indicate that network size, CCR values and initial load distribution have a significant impact on the algorithm's performances. Thus, this experimental study corroborate the usefulness of our algorithm, and confirms that when dealing with realistic model platforms, both {\it best effort} strategy and {\it virtual load} transfers play an important role on the achieved idle and convergence times.
+
+
+%Cas normal, ligne -> converge pas (effet d'escalier).
+%Avec vload, ça converge.
+
+%Dans les autres cas, résultats similaires au cas réel: redire que vload est
+%intéressant.
+
+%\FIXME{ajouter une courbe avec l'équilibrage en entier}
+
+%\FIXME{virer la metrique volume de comms}
+
+%\FIXME{ajouter une courbe ou on voit l'évolution de la charge en fonction du temps : avec et sans vload}
+
+% \begin{itemize}
+% \item cluster ou grid, entier ou réel, ne font pas de grosses différences
+% \item bookkeeping? améliore souvent les choses, parfois au prix d'un retard au démarrage
+% \item makhoul? se fait battre sur les grosses plateformes
+% \item taille de plateforme?
+% \item ratio comp/comm?
+% \item option $k$? peut-être intéressant sur des plateformes fortement interconnectées (hypercube)
+% \item volume de comm? souvent, besteffort/plain en fait plus. pourquoi?
+% \item répartition initiale de la charge ?
+% \item integer mode sur topo. line n'a jamais fini en plain? vérifier si ce n'est
+% pas à cause de l'effet d'escalier que bk est capable de gommer.
+% \end{itemize}}
