From: Arnaud Giersch <arnaud.giersch@univ-fcomte.fr>
Date: Thu, 14 Dec 2017 08:58:38 +0000 (+0100)
Subject: [sharelatex-git-integration Best effort strategy and virtual load for asynchronous... 
X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/loba-papers.git/commitdiff_plain/52e72953868418b69c0d5d8d1d67b3a2d2560e2f

[sharelatex-git-integration Best effort strategy and virtual load for asynchronous iterative load balancing 2017/12/14 09:58:38]
---

diff --git a/loba-besteffort/loba-besteffort.tex b/loba-besteffort/loba-besteffort.tex
index ee788a5..b94b8ef 100644
--- a/loba-besteffort/loba-besteffort.tex
+++ b/loba-besteffort/loba-besteffort.tex
@@ -68,7 +68,7 @@
   and their variations \cite{bcvc07:bc}, both load transfer and load information messages are dissociated. 
   To speedup the convergence time of the load balancing process, we propose {\it a clairvoyant virtual load} heuristic. This heuristic allows a node receiving a load
   information message to integrate the future virtual load (if any) in its load's list, even if the load has not been received yet. This leads to have predictive snapshots of nodes' loads at each iteration of the load balancing process.  Consequently, the notified node sends a real part of its load to some of
-  its neighbors taking into account the virtual load it will receive in the subsequent time-steps. Based on the SimGrid simulator, some series of test-bed scenarios are considered and many QoS metrics are evaluated to show the usefulness of the proposed algorithm.  %In order to validate our approaches, we have defined a
+  its neighbors taking into account the virtual load it will receive in the subsequent time-steps. Based on the SimGrid simulator, some series of test-bed scenarios are considered and several QoS metrics are evaluated to show the usefulness of the proposed algorithm.  %In order to validate our approaches, we have defined a
  % simulator based on SimGrid which allowed us to conduct many experiments.
 \end{abstract}
 
@@ -238,9 +238,8 @@ is linked to processor $2$ which is  also linked to processor $3$, but in which
 \end{align*}
 %{\bf RAPH, pourquoi il y a $x_3^2$?. Sinon il faudra reformuler la suite, c'est mal dit}
 
-Owing to the algorithm's specifications, processor $2$ can either send 
-a load to processor $1$ or processor
-$3$.  If it sends loads to processor $1$, it will not satisfy condition
+Owing to the algorithm's specifications, processor $2$ can either send a part of its load to processor $1$ or processor
+$3$.  If it sends to processor $1$, it will not satisfy condition
 \eqref{eq.ping-pong} because after that sending it will be less loaded than
 $x_3^2(t)$.  So we consider that the \emph{ping-pong} condition is probably too
 strong. %Currently, we did not try to make another convergence proof without this condition or with a weaker condition.