]> AND Private Git Repository - loba-papers.git/blob - supercomp11/supercomp11.tex
Logo AND Algorithmique Numérique Distribuée

Private GIT Repository
Simulation model.
[loba-papers.git] / supercomp11 / supercomp11.tex
1 \documentclass[smallextended]{svjour3}
2 \usepackage[utf8]{inputenc}
3 \usepackage[T1]{fontenc}
4 \usepackage{mathptmx}
5 \usepackage{amsmath}
6 \usepackage{courier}
7 \usepackage{graphicx}
8
9 \newcommand{\abs}[1]{\lvert#1\rvert} % \abs{x} -> |x|
10
11 \begin{document}
12
13 \title{Best effort strategy and virtual load
14   for asynchronous iterative load balancing}
15
16 \author{Raphaël Couturier \and
17         Arnaud Giersch \and
18         Abderrahmane Sider
19 }
20
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\\
25               \email{%
26                 raphael.couturier@univ-fcomte.fr,
27                 arnaud.giersch@univ-fcomte.fr}
28            \and
29            A. Sider \at
30               University of Béjaïa, Béjaïa, Algeria \\
31               \email{ar.sider@univ-bejaia.dz}
32 }
33
34 \maketitle
35
36
37 \begin{abstract}
38
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.
57
58
59 \end{abstract}
60
61 \section{Introduction}
62
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}.
81
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.
105
106
107
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
114 message also varies.
115
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.
124
125
126
127
128 \section{Bertsekas  and Tsitsiklis' asynchronous load balancing algorithm}
129 \label{BT algo}
130
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.
144
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:
150 \begin{equation}
151 x_i(t+1)=x_i(t)-\sum_{j\in V(i)} s_{ij}(t) + \sum_{j\in V(i)} r_{ji}(t)
152 \label{eq:ping-pong}
153 \end{equation}
154
155
156 Some  conditions are  required to  ensure the  convergence. One  of them  can be
157 called the \emph{ping-pong} condition which specifies that:
158 \begin{equation}
159 x_i(t)-\sum _{k\in V(i)} s_{ik}(t) \geq x_j^i(t)+s_{ij}(t)
160 \end{equation}
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.
164
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$:
169 \begin{eqnarray*}
170 x_1(t)=10   \\
171 x_2(t)=100   \\
172 x_3(t)=99.99\\
173  x_3^2(t)=99.99\\
174 \end{eqnarray*}
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.
181
182
183 \section{Best effort strategy}
184 \label{Best-effort}
185
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.
190
191 More precisely, when a processors $i$ is in its load-balancing phase,
192 he proceeds as following.
193 \begin{enumerate}
194 \item First, the neighbors are sorted in non-decreasing order of their
195   known loads $x^i_j(t)$.
196
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:
199   \begin{itemize}
200   \item the processor's own load, and
201   \item the mean of the loads of the selected neighbors and of the
202     processor's load.
203   \end{itemize}
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
206   the processor load:
207   \begin{equation*}
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)
210   \end{equation*}
211   The following properties hold:
212   \begin{equation*}
213     \begin{cases}
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) \\
218       \bar{x} \leq x_i(t)
219     \end{cases}
220   \end{equation*}
221
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) =
224   \bar{x} - x^i_j(t)$.
225
226   From the above equations, and notably from the definition of
227   $\bar{x}$, it can easily be verified that:
228   \begin{equation*}
229     \begin{cases}
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)
232     \end{cases}
233   \end{equation*}
234 \end{enumerate}
235
236 \section{Other strategies}
237 \label{Other}
238
239 \textbf{Question} faut-il décrire les stratégies makhoul et simple ?
240
241 \paragraph{simple} Tentative de respecter simplement les conditions de Bertsekas.
242 Parmi les voisins moins chargés que soi, on sélectionne :
243 \begin{itemize}
244 \item un des moins chargés (vmin) ;
245 \item un des plus chargés (vmax),
246 \end{itemize}
247 puis on équilibre avec vmin en s'assurant que notre charge reste
248 toujours supérieure à celle de vmin et à celle de vmax.
249
250 On envoie donc (avec "self" pour soi-même) :
251 \[
252     \min\left(\frac{load(self) - load(vmin)}{2}, load(self) - load(vmax)\right)
253 \]
254
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
257 voisins.
258
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.
262
263 C'est l'algorithme~2 dans~\cite{bahi+giersch+makhoul.2008.scalable}.
264
265 \section{Virtual load}
266 \label{Virtual load}
267
268 \section{Simulations}
269 \label{Simulations}
270
271 In order to test and validate our approaches, we wrote a simulator
272 using the SimGrid
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.
279
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}.
283
284 \subsection{Simulation model}
285 \label{Sim model}
286
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()}.}.
300
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.
304
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.
312
313 \paragraph{Computing thread} The computing thread is in charge of the
314 real load management.  It iteratively runs the following operations:
315 \begin{itemize}
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.
320 \end{itemize}
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).
324
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:
328 \begin{itemize}
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
334   iterate too fast.
335 \end{itemize}
336
337 \subsection{Validation of our approaches}
338 \label{Results}
339
340
341 On veut montrer quoi ? :
342
343 1) best plus rapide que les autres (simple, makhoul)
344 2) avantage virtual load
345
346 Est ce qu'on peut trouver des contre exemple?
347 Topologies variées
348
349
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
352
353
354 Expés avec ratio calcul/comm rapide et lent
355
356 Quelques expés avec charge initiale aléatoire plutot que sur le premier proc
357
358 Cadre processeurs homogènes
359
360 Topologies statiques
361
362 On ne tient pas compte de la vitesse des liens donc on la considère homogène
363
364 Prendre un réseau hétérogène et rendre processeur homogène
365
366 Taille : 10 100 très gros
367
368 \section{Conclusion and perspectives}
369
370
371 \bibliographystyle{spmpsci}
372 \bibliography{biblio}
373
374 \end{document}
375
376 %%% Local Variables:
377 %%% mode: latex
378 %%% TeX-master: t
379 %%% ispell-local-dictionary: "american"
380 %%% End:
381
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