1 \documentclass[smallextended]{svjour3}
2 \usepackage[utf8]{inputenc}
3 \usepackage[T1]{fontenc}
9 \newcommand{\abs}[1]{\lvert#1\rvert} % \abs{x} -> |x|
13 \title{Best effort strategy and virtual load
14 for asynchronous iterative load balancing}
16 \author{Raphaël Couturier \and
21 \institute{R. Couturier \and A. Giersch \at
22 LIFC, University of Franche-Comté, Belfort, France \\
23 % Tel.: +123-45-678910\\
24 % Fax: +123-45-678910\\
26 raphael.couturier@univ-fcomte.fr,
27 arnaud.giersch@univ-fcomte.fr}
30 University of Béjaïa, Béjaïa, Algeria \\
31 \email{ar.sider@univ-bejaia.dz}
39 Most of the time, asynchronous load balancing algorithms have extensively been
40 studied in a theoretical point of view. The Bertsekas and Tsitsiklis'
41 algorithm~\cite[section~7.4]{bertsekas+tsitsiklis.1997.parallel}
42 is certainly the most well known algorithm for which the convergence proof is
43 given. From a practical point of view, when a node wants to balance a part of
44 its load to some of its neighbors, the strategy is not described. In this
45 paper, we propose a strategy called \emph{best effort} which tries to balance
46 the load of a node to all its less loaded neighbors while ensuring that all the
47 nodes concerned by the load balancing phase have the same amount of load.
48 Moreover, asynchronous iterative algorithms in which an asynchronous load
49 balancing algorithm is implemented most of the time can dissociate messages
50 concerning load transfers and message concerning load information. In order to
51 increase the converge of a load balancing algorithm, we propose a simple
52 heuristic called \emph{virtual load} which allows a node that receives an load
53 information message to integrate the load that it will receive later in its
54 load (virtually) and consequently sends a (real) part of its load to some of its
55 neighbors. In order to validate our approaches, we have defined a simulator
56 based on SimGrid which allowed us to conduct many experiments.
61 \section{Introduction}
63 Load balancing algorithms are extensively used in parallel and distributed
64 applications in order to reduce the execution times. They can be applied in
65 different scientific fields from high performance computation to micro sensor
66 networks. They are iterative by nature. In literature many kinds of load
67 balancing algorithms have been studied. They can be classified according
68 different criteria: centralized or decentralized, in static or dynamic
69 environment, with homogeneous or heterogeneous load, using synchronous or
70 asynchronous iterations, with a static topology or a dynamic one which evolves
71 during time. In this work, we focus on asynchronous load balancing algorithms
72 where computer nodes are considered homogeneous and with homogeneous load with
73 no external load. In this context, Bertsekas and Tsitsiklis have proposed an
74 algorithm which is definitively a reference for many works. In their work, they
75 proved that under classical hypotheses of asynchronous iterative algorithms and
76 a special constraint avoiding \emph{ping-pong} effect, an asynchronous
77 iterative algorithm converge to the uniform load distribution. This work has
78 been extended by many authors. For example,
79 DASUD~\cite{cortes+ripoll+cedo+al.2002.asynchronous} propose a version working
80 with integer load. {\bf Rajouter des choses ici}.
82 Although the Bertsekas and Tsitsiklis' algorithm describes the condition to
83 ensure the convergence, there is no indication or strategy to really implement
84 the load distribution. In other word, a node can send a part of its load to one
85 or many of its neighbors while all the convergence conditions are
86 followed. Consequently, we propose a new strategy called \emph{best effort}
87 that tries to balance the load of a node to all its less loaded neighbors while
88 ensuring that all the nodes concerned by the load balancing phase have the same
89 amount of load. Moreover, when real asynchronous applications are considered,
90 using asynchronous load balancing algorithms can reduce the execution
91 times. Most of the times, it is simpler to distinguish load information messages
92 from data migration messages. Formers ones allows a node to inform its
93 neighbors of its current load. These messages are very small, they can be sent
94 quite often. For example, if an computing iteration takes a significant times
95 (ranging from seconds to minutes), it is possible to send a new load information
96 message at each neighbor at each iteration. Latter messages contains data that
97 migrates from one node to another one. Depending on the application, it may have
98 sense or not that nodes try to balance a part of their load at each computing
99 iteration. But the time to transfer a load message from a node to another one is
100 often much more longer that to time to transfer a load information message. So,
101 when a node receives the information that later it will receive a data message,
102 it can take this information into account and it can consider that its new load
103 is larger. Consequently, it can send a part of it real load to some of its
104 neighbors if required. We call this trick the \emph{virtual load} mechanism.
108 So, in this work, we propose a new strategy for improving the distribution of
109 the load and a simple but efficient trick that also improves the load
110 balancing. Moreover, we have conducted many simulations with SimGrid in order to
111 validate our improvements are really efficient. Our simulations consider that in
112 order to send a message, a latency delays the sending and according to the
113 network performance and the message size, the time of the reception of the
116 In the following of this paper, Section~\ref{BT algo} describes the Bertsekas
117 and Tsitsiklis' asynchronous load balancing algorithm. Moreover, we present a
118 possible problem in the convergence conditions. Section~\ref{Best-effort}
119 presents the best effort strategy which provides an efficient way to reduce the
120 execution times. In Section~\ref{Virtual load}, the virtual load mechanism is
121 proposed. Simulations allowed to show that both our approaches are valid using a
122 quite realistic model detailed in Section~\ref{Simulations}. Finally we give a
123 conclusion and some perspectives to this work.
128 \section{Bertsekas and Tsitsiklis' asynchronous load balancing algorithm}
131 In order prove the convergence of asynchronous iterative load balancing
132 Bertsekas and Tsitsiklis proposed a model
133 in~\cite{bertsekas+tsitsiklis.1997.parallel}. Here we recall some notations.
134 Consider that $N={1,...,n}$ processors are connected through a network.
135 Communication links are represented by a connected undirected graph $G=(N,V)$
136 where $V$ is the set of links connecting different processors. In this work, we
137 consider that processors are homogeneous for sake of simplicity. It is quite
138 easy to tackle the heterogeneous case~\cite{ElsMonPre02}. Load of processor $i$
139 at time $t$ is represented by $x_i(t)\geq 0$. Let $V(i)$ be the set of
140 neighbors of processor $i$. Each processor $i$ has an estimate of the load of
141 each of its neighbors $j \in V(i)$ represented by $x_j^i(t)$. According to
142 asynchronism and communication delays, this estimate may be outdated. We also
143 consider that the load is described by a continuous variable.
145 When a processor send a part of its load to one or some of its neighbors, the
146 transfer takes time to be completed. Let $s_{ij}(t)$ be the amount of load that
147 processor $i$ has transferred to processor $j$ at time $t$ and let $r_{ij}(t)$ be the
148 amount of load received by processor $j$ from processor $i$ at time $t$. Then
149 the amount of load of processor $i$ at time $t+1$ is given by:
151 x_i(t+1)=x_i(t)-\sum_{j\in V(i)} s_{ij}(t) + \sum_{j\in V(i)} r_{ji}(t)
156 Some conditions are required to ensure the convergence. One of them can be
157 called the \emph{ping-pong} condition which specifies that:
159 x_i(t)-\sum _{k\in V(i)} s_{ik}(t) \geq x_j^i(t)+s_{ij}(t)
161 for any processor $i$ and any $j \in V(i)$ such that $x_i(t)>x_j^i(t)$. This
162 condition aims at avoiding a processor to send a part of its load and being
163 less loaded after that.
165 Nevertheless, we think that this condition may lead to deadlocks in some
166 cases. For example, if we consider only three processors and that processor $1$
167 is linked to processor $2$ which is also linked to processor $3$ (i.e. a simple
168 chain which 3 processors). Now consider we have the following values at time $t$:
175 In this case, processor $2$ can either sends load to processor $1$ or processor
176 $3$. If it sends load to processor $1$ it will not satisfy condition
177 (\ref{eq:ping-pong}) because after the sending it will be less loaded that
178 $x_3^2(t)$. So we consider that the \emph{ping-pong} condition is probably to
179 strong. Currently, we did not try to make another convergence proof without this
180 condition or with a weaker condition.
183 \section{Best effort strategy}
186 We will describe here a new load-balancing strategy that we called
187 \emph{best effort}. The general idea behind this strategy is, for a
188 processor, to send some load to the most of its neighbors, doing its
189 best to reach the equilibrium between those neighbors and himself.
191 More precisely, when a processors $i$ is in its load-balancing phase,
192 he proceeds as following.
194 \item First, the neighbors are sorted in non-decreasing order of their
195 known loads $x^i_j(t)$.
197 \item Then, this sorted list is traversed in order to find its largest
198 prefix such as the load of each selected neighbor is lesser than:
200 \item the processor's own load, and
201 \item the mean of the loads of the selected neighbors and of the
204 Let's call $S_i(t)$ the set of the selected neighbors, and
205 $\bar{x}(t)$ the mean of the loads of the selected neighbors and of
208 \bar{x}(t) = \frac{1}{\abs{S_i(t)} + 1}
209 \left( x_i(t) + \sum_{j\in S_i(t)} x^i_j(t) \right)
211 The following properties hold:
214 S_i(t) \subset V(i) \\
215 x^i_j(t) < x_i(t) & \forall j \in S_i(t) \\
216 x^i_j(t) < \bar{x} & \forall j \in S_i(t) \\
217 x^i_j(t) \leq x^i_k(t) & \forall j \in S_i(t), \forall k \in V(i) \setminus S_i(t) \\
222 \item Once this selection is completed, processor $i$ sends to each of
223 the selected neighbor $j\in S_i(t)$ an amount of load $s_{ij}(t) =
226 From the above equations, and notably from the definition of
227 $\bar{x}$, it can easily be verified that:
230 x_i(t) - \sum_{j\in S_i(t)} s_{ij}(t) = \bar{x} \\
231 x^i_j(t) + s_{ij}(t) = \bar{x} & \forall j \in S_i(t)
236 \section{Other strategies}
239 \textbf{Question} faut-il décrire les stratégies makhoul et simple ?
241 \paragraph{simple} Tentative de respecter simplement les conditions de Bertsekas.
242 Parmi les voisins moins chargés que soi, on sélectionne :
244 \item un des moins chargés (vmin) ;
245 \item un des plus chargés (vmax),
247 puis on équilibre avec vmin en s'assurant que notre charge reste
248 toujours supérieure à celle de vmin et à celle de vmax.
250 On envoie donc (avec "self" pour soi-même) :
252 \min\left(\frac{load(self) - load(vmin)}{2}, load(self) - load(vmax)\right)
255 \paragraph{makhoul} Ordonne les voisins du moins chargé au plus chargé
256 puis calcule les différences de charge entre soi-même et chacun des
259 Ensuite, pour chaque voisin, dans l'ordre, et tant qu'on reste plus
260 chargé que le voisin en question, on lui envoie 1/(N+1) de la
261 différence calculée au départ, avec N le nombre de voisins.
263 C'est l'algorithme~2 dans~\cite{bahi+giersch+makhoul.2008.scalable}.
265 \section{Virtual load}
268 \section{Simulations}
271 In order to test and validate our approaches, we wrote a simulator
273 framework~\cite{casanova+legrand+quinson.2008.simgrid}. This
274 simulator, which consists of about 2,700 lines of C++, allows to run
275 the different load-balancing strategies under various parameters, such
276 as the initial distribution of load, the interconnection topology, the
277 characteristics of the running platform, etc. Then several metrics
278 are issued that permit to compare the strategies.
280 The simulation model is detailed in the next section (\ref{Sim
281 model}), then the results of the simulations are presented in
282 section~\ref{Results}.
284 \subsection{Simulation model}
287 In the simulation model the processors exchange messages which are of
288 two kinds. First, there are \emph{control messages} which only carry
289 information that is exchanged between the processors, such as the
290 current load, or the virtual load transfers if this option is
291 selected. These messages are rather small, and their size is
292 constant. Then, there are \emph{data messages} that carry the real
293 load transferred between the processors. The size of a data message
294 is a function of the amount of load that it carries, and it can be
295 pretty large. In order to receive the messages, each processor has
296 two receiving channels, one for each kind of messages. Finally, when
297 a message is sent or received, this is done by using the non-blocking
298 primitives of SimGrid\footnote{That are \texttt{MSG\_task\_isend()},
299 and \texttt{MSG\_task\_irecv()}.}.
301 During the simulation, each processor concurrently runs three threads:
302 a \emph{receiving thread}, a \emph{computing thread}, and a
303 \emph{load-balancing thread}, which we will briefly describe now.
305 \paragraph{Receiving thread} The receiving thread is in charge of
306 waiting for messages to come, either on the control channel, or on the
307 data channel. When a message is received, it is pushed in a buffer of
308 received message, to be later consumed by one of the other threads.
309 There are two such buffers, one for the control messages, and one for
310 the data messages. The buffers are implemented with a lock-free FIFO
311 \cite{sutter.2008.writing} to avoid contention between the threads.
313 \paragraph{Computing thread} The computing thread is in charge of the
314 real load management. It iteratively runs the following operations:
316 \item if some load was received from the neighbors, get it;
317 \item if there is some load to send to the neighbors, send it;
318 \item run some computation, whose duration is function of the current
319 load of the processor.
321 Practically, after the computation, the computing thread waits for a
322 small amount of time if the iterations are looping too fast (for
323 example, when the current load is zero).
325 \paragraph{Load-balancing thread} The load-balancing thread is in
326 charge of running the load-balancing algorithm, and exchange the
327 control messages. It iteratively runs the following operations:
329 \item get the control messages that were received from the neighbors;
330 \item run the load-balancing algorithm;
331 \item send control messages to the neighbors, to inform them of the
332 processor's current load, and possibly of virtual load transfers;
333 \item wait a minimum (configurable) amount of time, to avoid to
337 \subsection{Validation of our approaches}
341 On veut montrer quoi ? :
343 1) best plus rapide que les autres (simple, makhoul)
344 2) avantage virtual load
346 Est ce qu'on peut trouver des contre exemple?
350 Simulation avec temps définies assez long et on mesure la qualité avec : volume de calcul effectué, volume de données échangées
351 Mais aussi simulation avec temps court qui montre que seul best converge
354 Expés avec ratio calcul/comm rapide et lent
356 Quelques expés avec charge initiale aléatoire plutot que sur le premier proc
358 Cadre processeurs homogènes
362 On ne tient pas compte de la vitesse des liens donc on la considère homogène
364 Prendre un réseau hétérogène et rendre processeur homogène
366 Taille : 10 100 très gros
368 \section{Conclusion and perspectives}
371 \bibliographystyle{spmpsci}
372 \bibliography{biblio}
379 %%% ispell-local-dictionary: "american"
382 % LocalWords: Raphaël Couturier Arnaud Giersch Abderrahmane Sider Franche ij
383 % LocalWords: Bertsekas Tsitsiklis SimGrid DASUD Comté Béjaïa asynchronism ji
384 % LocalWords: ik isend irecv