Merged

report/sections/annexes.tex

@@ -55,7 +55,12 @@ \subsection{Graphes partie critique}
 \newpage
 
 \subsection{Comparaison des performances}
-\label{sec:perf_plot}
+
+\label{sec:plot_1_recv}
+
+\label{sec:plot_mul_recv}
+
+\label{sec:plot_max}
 
 
 \end{document}

report/sections/performances.tex

@@ -11,16 +11,24 @@ \section{Performances}
 Par exemple, le processeurs est constitué de 4 modules de 4 coeurs (appelés \textit{CCX} par le frabricant). Nous avons donc optimisé chaque exécution
 en groupant les \textit{threads} d'un même \textit{stream} dans un même \textit{CCX}.
 
-Le premier test compare les performances de l'implémentation multithreadée avec un seul \textit{receiver} et un nombre variable de \textit{handlers}  %TODO: note de bas de page
+Le premier test (cfr : \hyperref[sec:plot_1_recv]{\textit{test 1}}) compare les performances de l'implémentation multithreadée avec un seul \textit{receiver} et un nombre variable de \textit{handlers} 
 en fonction du nombre de clients avec, comme référence, celles de l'implémentation de base\footnote{Le \textit{receiver} base rencontrant des 
 difficutés à transmettre des fichier pour un nombre de clients trop élevés, les débits pour plus de 10 clients n'ont pas été indiquées mais sont 
 supposées constante.} ainsi que celles de l'implémentation en mode séquentiel.          %TODO : add reference to figure
 On observe sur la figure une nette augmentation du débit avec le nombre de \textit{handlers}, ce qui corresponds à nos attentes. Néanmoins, cette 
 tendance s'inverse à très petit nombre de clients (moins de 3) où l'exécution séquentielle deviens plus performante et l'exécution avec trois \textit{handlers} étant 
 presque deux fois plus lente que l'implémentation de base. Il faut bien noter que cette tendance s'inverse à plus haut nombre de clients.
 
-Un deuxième test compare ces performances en augmentant aussi le nombre de \textit{receiver}, tout en gardant la même référence. On peut voir qu'ajouter 
-des \textit{receiver} permet, d'une part, de réduire les pertes de performances à bas nombre de clients ()
+Un deuxième test (cfr : \hyperref[sec:plot_mul_recv]{\textit{test 2}}) compare ces performances en augmentant aussi le nombre de \textit{receiver}, tout en gardant la même référence. On peut voir qu'ajouter 
+des \textit{receiver} permet, d'une part, de réduire les pertes de performances à bas nombre de clients et, d'autre part, d'augmenter les performances à 
+grand nombre de clients\footnote{l'exécution avec 2 \textit{handler} passe de 170 \nicefrac{MB}{s} à 215 pour 100 clients}. De plus, avec un seul 
+\textit{receiver}, les performances finissent par plafonner à une valeur égale au débit maximal de données traitées par un \textit{receiver}. Augmenter 
+la valeur de l'argument N peret donc de multiplier la valeur de ce plafond.
+
+Finalement, les limites de l'implémentation ont été testées : les paramètres $N = 4$ et $n = 12$ donnant les meilleurs résultats, leur performances ont été 
+testées sur un nombre de clients bien plus grand (cfr : \hyperref[sec:plot_max]{\textit{test 3}}). Des valeurs plus élevées que 1000 clients n'ont pas été 
+testées à cause de problème pour générer assez de clients assez vite rendant toute mesure inutile.
+Ce test nous montre le comportement de notre application dans des conditions optimales: Une forte variation de débit jusqu'à ~ 12 clients puis un plafond à 625 \nicefrac{MB}{s}.