\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{mathptmx}
+\usepackage{amsmath}
\usepackage{courier}
\usepackage{graphicx}
+\newcommand{\abs}[1]{\lvert#1\rvert} % \abs{x} -> |x|
+
\begin{document}
-\title{Best effort strategy and virtual load for asynchronous iterative load balancing}
+\title{Best effort strategy and virtual load
+ for asynchronous iterative load balancing}
\author{Raphaël Couturier \and
Arnaud Giersch \and
Abderrahmane Sider
}
-\institute{F. Author \at
- first address \\
- Tel.: +123-45-678910\\
- Fax: +123-45-678910\\
- \email{fauthor@example.com} % \\
-% \emph{Present address:} of F. Author % if needed
+\institute{R. Couturier \and A. Giersch \at
+ LIFC, University of Franche-Comté, Belfort, France \\
+ % Tel.: +123-45-678910\\
+ % Fax: +123-45-678910\\
+ \email{%
+ raphael.couturier@univ-fcomte.fr,
+ arnaud.giersch@univ-fcomte.fr}
\and
- S. Author \at
- second address
+ A. Sider \at
+ University of Béjaïa, Béjaïa, Algeria \\
+ \email{ar.sider@univ-bejaia.dz}
}
\maketitle
is certainly the most well known algorithm for which the convergence proof is
given. From a practical point of view, when a node wants to balance a part of
its load to some of its neighbors, the strategy is not described. In this
-paper, we propose a strategy called \texttt{best effort} which tries to balance
+paper, we propose a strategy called \emph{best effort} which tries to balance
the load of a node to all its less loaded neighbors while ensuring that all the
nodes concerned by the load balancing phase have the same amount of load.
Moreover, asynchronous iterative algorithms in which an asynchronous load
balancing algorithm is implemented most of the time can dissociate messages
concerning load transfers and message concerning load information. In order to
increase the converge of a load balancing algorithm, we propose a simple
-heuristic called \texttt{virtual load} which allows a node that receives an load
+heuristic called \emph{virtual load} which allows a node that receives an load
information message to integrate the load that it will receive later in its
load (virtually) and consequently sends a (real) part of its load to some of its
neighbors. In order to validate our approaches, we have defined a simulator
no external load. In this context, Bertsekas and Tsitsiklis have proposed an
algorithm which is definitively a reference for many works. In their work, they
proved that under classical hypotheses of asynchronous iterative algorithms and
-a special constraint avoiding \texttt{ping-pong} effect, an asynchronous
+a special constraint avoiding \emph{ping-pong} effect, an asynchronous
iterative algorithm converge to the uniform load distribution. This work has
been extended by many authors. For example,
DASUD~\cite{cortes+ripoll+cedo+al.2002.asynchronous} propose a version working
ensure the convergence, there is no indication or strategy to really implement
the load distribution. In other word, a node can send a part of its load to one
or many of its neighbors while all the convergence conditions are
-followed. Consequently, we propose a new strategy called \texttt{best effort}
+followed. Consequently, we propose a new strategy called \emph{best effort}
that tries to balance the load of a node to all its less loaded neighbors while
ensuring that all the nodes concerned by the load balancing phase have the same
amount of load. Moreover, when real asynchronous applications are considered,
when a node receives the information that later it will receive a data message,
it can take this information into account and it can consider that its new load
is larger. Consequently, it can send a part of it real load to some of its
-neighbors if required. We call this trick the \texttt{virtual load} mecanism.
+neighbors if required. We call this trick the \emph{virtual load} mecanism.
the amount of load of processor $i$ at time $t+1$ is given by:
\begin{equation}
x_i(t+1)=x_i(t)-\sum_{j\in V(i)} s_{ij}(t) + \sum_{j\in V(i)} r_{ji}(t)
+\label{eq:ping-pong}
+\end{equation}
+
+
+Some conditions are required to ensure the convergence. One of them can be
+called the \emph{ping-pong} condition which specifies that:
+\begin{equation}
+x_i(t)-\sum _{k\in V(i)} s_{ik}(t) \geq x_j^i(t)+s_{ij}(t)
\end{equation}
+for any processor $i$ and any $j \in V(i)$ such that $x_i(t)>x_j^i(t)$. This
+condition aims at avoiding a processor to send a part of its load and beeing
+less loaded after that.
+
+Nevertheless, we think that this condition may lead to deadlocks in some
+cases. For example, if we consider only three processors and that processor $1$
+is linked to processor $2$ which is also linked to processor $3$ (i.e. a simple
+chain wich 3 processors). Now consider we have the following values at time $t$:
+\begin{eqnarray*}
+x_1(t)=10 \\
+x_2(t)=100 \\
+x_3(t)=99.99\\
+ x_3^2(t)=99.99\\
+\end{eqnarray*}
+In this case, processor $2$ can either sends load to processor $1$ or processor
+$3$. If it sends load to processor $1$ it will not satisfy condition
+(\ref{eq:ping-pong}) because after the sending it will be less loaded that
+$x_3^2(t)$. So we consider that the \emph{ping-pong} condition is probably to
+strong. Currently, we did not try to make another convergence proof without this
+condition or with a weaker condition.
\section{Best effort strategy}
\label{Best-effort}
-
+We will describe here a new load-balancing strategy that we called
+\emph{best effort}. The general idea behind this strategy is, for a
+processor, to send some load to the most of its neighbors, doing its
+best to reach the equilibrium between those neighbors and himself.
+
+More precisely, when a processors $i$ is in its load-balancing phase,
+he proceeds as following.
+\begin{enumerate}
+\item First, the neighbors are sorted in non-decreasing order of their
+ known loads $x^i_j(t)$.
+
+\item Then, this sorted list is traversed in order to find its largest
+ prefix such as the load of each selected neighbor is lesser than:
+ \begin{itemize}
+ \item the processor's own load, and
+ \item the mean of the loads of the selected neighbors and of the
+ processor's load.
+ \end{itemize}
+ Let's call $S_i(t)$ the set of the selected neighbors, and
+ $\bar{x}(t)$ the mean of the loads of the selected neighbors and of
+ the processor load:
+ \begin{equation*}
+ \bar{x}(t) = \frac{1}{\abs{S_i(t)} + 1}
+ \left( x_i(t) + \sum_{j\in S_i(t)} x^i_j(t) \right)
+ \end{equation*}
+ The following properties hold:
+ \begin{equation*}
+ \begin{cases}
+ S_i(t) \subset V(i) \\
+ x^i_j(t) < x_i(t) & \forall j \in S_i(t) \\
+ x^i_j(t) < \bar{x} & \forall j \in S_i(t) \\
+ x^i_j(t) \leq x^i_k(t) & \forall j \in S_i(t), \forall k \in V(i) \setminus S_i(t) \\
+ \bar{x} \leq x_i(t)
+ \end{cases}
+ \end{equation*}
+
+\item Once this selection is completed, processor $i$ sends to each of
+ the selected neighbor $j\in S_i(t)$ an amount of load $s_{ij}(t) =
+ \bar{x} - x^i_j(t)$.
+
+ From the above equations, and notably from the definition of
+ $\bar{x}$, it can easily be verified that:
+ \begin{equation*}
+ \begin{cases}
+ x_i(t) - \sum_{j\in S_i(t)} s_{ij}(t) = \bar{x} \\
+ x^i_j(t) + s_{ij}(t) = \bar{x} & \forall j \in S_i(t)
+ \end{cases}
+ \end{equation*}
+\end{enumerate}
+
+\section{Other strategies}
+\label{Other}
+
+\textbf{Question} faut-il décrire les stratégies makhoul et simple ?
+
+\paragraph{simple} Tentative de respecter simplement les conditions de Bertsekas.
+Parmi les voisins moins chargés que soi, on sélectionne :
+\begin{itemize}
+\item un des moins chargés (vmin) ;
+\item un des plus chargés (vmax),
+\end{itemize}
+puis on équilibre avec vmin en s'assurant que notre charge reste
+toujours supérieure à celle de vmin et à celle de vmax.
+
+On envoie donc (avec "self" pour soi-même) :
+\[
+ \min\left(\frac{load(self) - load(vmin)}{2}, load(self) - load(vmax)\right)
+\]
+
+\paragraph{makhoul} Ordonne les voisins du moins chargé au plus chargé
+puis calcule les différences de charge entre soi-même et chacun des
+voisins.
+
+Ensuite, pour chaque voisin, dans l'ordre, et tant qu'on reste plus
+chargé que le voisin en question, on lui envoie 1/(N+1) de la
+différence calculée au départ, avec N le nombre de voisins.
+
+C'est l'algorithme~2 dans~\cite{bahi+giersch+makhoul.2008.scalable}.
\section{Virtual load}
\label{Virtual load}
\section{Simulations}
\label{Simulations}
+In order to test and validate our approaches, we wrote a simulator
+using the SimGrid
+framework~\cite{casanova+legrand+quinson.2008.simgrid}. The process
+model is detailed in the next section (\ref{Sim model}), then the
+results of the simulations are presented in section~\ref{Results}.
+
\subsection{Simulation model}
+\label{Sim model}
+
+\begin{verbatim}
+Communications
+==============
+
+There are two receiving channels per host: control for information
+messages, and data for load transfers.
+
+Process model
+=============
+
+Each process is made of 3 threads: a receiver thread, a computing
+thread, and a load-balancer thread.
+
+* Receiver thread
+ ---------------
+
+ Loop
+ | wait for a message to come, either on data channel, or on ctrl channel
+ | push received message in a buffer of received messages
+ | -> ctrl messages on the one side
+ | -> data messages on the other side
+ +-
+
+ The loop terminates when a "finalize" message is received on each
+ channel.
+
+* Computing thread
+ ----------------
+
+ Loop
+ | if we received some real load, get it (data messages)
+ | if there is some real load to send, send it
+ | if we own some load, simulate some computing on it
+ | sleep a bit if we are looping too fast
+ +-
+ send CLOSE on data for all neighbors
+ wait for CLOSE on data from all neighbors
+
+ The loop terminates when process::still_running() returns false.
+ (read the source for full details...)
+
+* Load-balancing thread
+ ---------------------
+
+ Loop
+ | call load-balancing algorithm
+ | send ctrl messages
+ | sleep (min_lb_iter_duration)
+ | receive ctrl messages
+ +-
+ send CLOSE on ctrl for all neighbors
+ wait for CLOSE on ctrl from all neighbors
+
+ The loop terminates when process::still_running() returns false.
+ (read the source for full details...)
+\end{verbatim}
\subsection{Validation of our approaches}
+\label{Results}
On veut montrer quoi ? :
