WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

La tolérance aux pannes des algorithmes de partage de ressources dans les systèmes répartis et les réseaux Ad Hoc (simulation par ns-2)

( Télécharger le fichier original )
par Sami et Abdelmadjid Oubbati et Benarfa
Université Amar Telidji Laghouat - Ingénieur d'état en informatique 2010
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

3.9.3 Résultats et interprétations

Afin d'étudier la performance de ce nouvel algorithme, nous avons réalisé une simulation par les mêmes paramètres précédents et on a fixé le nombre de pannes à trois pannes dans chaque scénario.

3.9.3.1 Variation du nombre de requêtes

(a) (b)

Figure 3.21 - Influence du nombre de requête sur le NMM et TAM. 3.9.3.2 Variation du nombre de ressources

(a)

(b)

Figure 3.22 - Influence du nombre de ressource sur le NMM et TAM.

3.9.3.3 Variation du nombre de sites

(a)

(b)

Figure 3.23 - Influence du nombre de site sur le NMM et TAM.

D'après les courbes obtenues on remarque que le nouvel algorithme propose a respecte le même comportement avec l'algorithme initial, on peut dire donc que la tolerance aux pannes n'a pas influence sur la performance de notre algorithme.

Il faut comme même dire qu'il y a une faible augmentation dans le NMM, cela est justifie par l'echange continu des messages Information et Nouveau_Racine.

Un problème : (Nombre de messages un peu élevé)

Malgre que la solution precedente a rendu notre algorithme tolerant aux pannes, nous avons remarque que le nombre de message echanges de cet algorithme depasse celui de l'algorithme initial, cela est justifie par les messages Information et Nouveau_Racine qui sont important pour assurer la tolerance aux pannes, et par les autres messages echanges lorsqu'une racine revient de son etat de panne.

Une solution proposée

Puisque le Sous_Racine peut remplacer son racine en cas de panne sans aucun problème, il parait inutile que la racine defaillante reprends sa place lorsqu'elle revient de l'etat de panne, donc on peut eviter l'echange eleve de messages en respectant la même racine et en considerant l'ancien racine comme un site simple. Cette amelioration va nous permettre de minimiser le NMM, tout en gardant la performance de l'algorithme A3.

3.10 AMtLioRATioN (ALGoRiTHME ToLtRANT AuX pANNEs AMtLioRt) Nous allons effectuer le changement suivant :

- Lorsque la racine revient de son etat de panne, elle sera consideree comme un site simple, ses prochaines requêtes seront demandees de la racine de son arbre.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Nous voulons explorer la bonté contrée énorme où tout se tait"   Appolinaire