RICM4: Évaluation de Performance

Mesures

ping -D liglab.imag.fr > liglab.log 2>&1
ping -D liglab.imag.fr -s 20480 -i .2

while true ; do for i in 16 60 600 1600 ; do ping -c 2 -D liglab.imag.fr -s $i -i .2 | grep from; done ; done

# Celui ci permet de se prémunir d'un certain nombre de biais et
# de collecter relativement rapidement des mesures
while true ; do \
    export j=$(($RANDOM%2000)) ; \
    ping -c 1 -D liglab.imag.fr -s $j  | grep from ; \
    sleep .2 ; \
done > /tmp/liglab2.log

  $#ARGV==1 or die "Usage: convert.pl <input.log> <output.csv> -->'$#ARGV'";
  $input = $ARGV[0];
  $output = $ARGV[1];
  open(INPUT,$input) or die;
  open(OUTPUT,"> $output") or die;
  $l=<INPUT>;
  print OUTPUT qw(time,size,name,ip,seq,ttl,delay)."\n";

  while(defined($l=<INPUT>)) { 
      chomp($l);
      if($l eq "") { last; }
      if($l =~ /^\[(.*)\] (.*) bytes from (.*) \((.*)\): icmp_seq=(.*) ttl=(.*) time=(.*) ms$/) {
          my($time,$size,$name,$ip,$seq,$ttl,$delay)=($1,$2,$3,$4,$5,$6,$7);
          print OUTPUT (join(',',($time,$size,$name,$ip,$seq,$ttl,$delay))."\n");
      } else { print "---> $l\n"; }
  }

---> [1421761684.770828] 21 bytes from lig-publig.imag.fr (129.88.11.7): icmp_seq=1 ttl=60
---> [1421761706.146320] 9 bytes from lig-publig.imag.fr (129.88.11.7): icmp_seq=1 ttl=60
---> [1421761748.647974] 9 bytes from lig-publig.imag.fr (129.88.11.7): icmp_seq=1 ttl=60
---> [1421761788.500516] 9 bytes from lig-publig.imag.fr (129.88.11.7): icmp_seq=1 ttl=60
...

for i in `find RICM4_EP_ping -name '*.gz'` ; do echo "- [[http://mescal.imag.fr/membres/arnaud.legrand/teaching/2014/$i][$i]]"; done

Fotsing: http://rpubs.com/emfotsing/65717

• Q1
  

  Vous n'avez pas compris la questions. Ce qu'on voulait étudier, c'est la distribution du temps de service. Regardez le corrigé.

• Q2
  

  Vous n'avez du coup pas compris ce qui importait dans les paramètres de la loi du temps de service. Quand vous faites:

  All_Policies_Experiments_Exp <- Gen_All_Policies_Experiments(policy="exp",x=1/5)
  

  vous considérez un serveur capable de traiter en moyenne \(1/5=0.2\) tâches par seconde. J'avais demandé de normaliser le temps de service à 1. Du coup, quand dans la suite, vous utilisez des taux d'arrivée de 0.2, 0.4, 0.6 ou 0.8, vous injectez les tâches à une vitesse bien supérieure à ce que le serveur est capable de traiter. C'est pour ça que vos temps de service sont aussi élevés. Le système est saturé et ces valeurs n'ont pas de sens. Regardez la correction.

  Ce qui est curieux, c'est que vous avez visiblement compris que le système était instable. Mais vous n'avez pas compris à quoi c'était dû (un serveur trop lent ici par rapport à la charge que vous injectiez) et du coup, vous n'avez pas pu observer grand chose.

Guo Kai & Yao Longfei: http://rpubs.com/GUOKAI/65454

• Q1
  

  Dans l'ensemble, vous avez inversé la question 1 et la question 2 mais bon, passons. En ce qui concerne la question 1, vous n'avez pas compris ce que je vous demandais. On s'intéressait à la distribution du temps de service et faire un sequence plot n'est pas la meilleure représentation… De même pour la question 2, tracer dans un graphe la moyenne et dans un autre la variance, n'est pas la meilleur représentation. L'utilisation d'intervalles de confiance aurait été bien plus adaptée et vous aurait permis de comparer les politiques entre elles. Regardez bien la correction.

  Sinon, la longue série des p111, p112, …, p444. BERK! Quelle idée d'abuser ainsi du copier/coller. Les boucles for, c'est fait pour quoi selon vous ?

  Pareil pour la façon dont vous faites l'agrégation. Je vous avais justement montré plyr pour éviter ce genre d'horreurs…

  Pour ce qui est de l'analyse que vous faites, c'est étrange car vous raisonnez comme si la loi du temps de service était un choix. C'est plutôt quelque chose d'imposé par le système que vous observez. Ce sur quoi vous pouvez plutôt agir, c'est la politique de service…

• Q2
  
• Q3
  

  Pas de réponse

Vincent Mesnier & Jake Morison

• Q1
  

  Ce ne sont pas les représentations les plus adaptées. Un histogramme aurait été plus judicieux. Il aurait également été mieux de représenter les différents histogrammes sur le même graphe pour mieux les comparer.

• Q2
  

  Le graphe est très bien. Par contre, votre lecture est étrange (d'ailleurs, c'est "amusant", c'est exactement les mêmes erreurs que Saussac et Toussaint):

  • "une evolution plutot régulière", tout à fait d'accord
  • "(elles suivent à peu prés une droite)". Hein ? Ben non, ce n'est pas droit.
  • "il y en a une qui se dermarque : la bleue (préemption avec restart).". Effectivement.
  • "Cette aumgentation est proche de l’exponentielle." Non, vous ne pouvez pas dire ça. Vous n'avez que deux points et une exponentielle, ça n'est pas une asymptote. Ça "explose", oui, mais pas comme une exponentielle.
  • "Si nous regardons de plus prés la courbe orange (sans préemption), on remarque qu’elle semble etre la plus efficace car elle fourni pour chaque valeur un temps de service minimal." Non, justement, si vous regardez bien, vous verrez que vos intervalles de confiance se recouvrent et que, même si c'est pmtn, la verte, la plus basse, ça n'est pas significatif.
• Q3
  

  Encore une fois ici, vos erreurs sont exactement les mêmes que celles de Saussac et Toussaint. Je n'aime pas ça du tout.

  Ce qui nous intéressait ici, c'est plutôt pour une loi donnée, comment les différentes politiques se comparent les unes aux autres. Et au delà de constater que telle ou telle politique se comporte mieux que telle autre, ce qui est important, c'est de chercher à expliquer pourquoi… Lisez bien mon corrigé.

  Enfin, concernant votre conclusion qui lie les statistiques au bikinis, je ne suis pas sûr qu'elle soit des plus adaptées ici…

Thibault SAUSSAC​ & Sébastien TOUSSAINT​

• Q1
  

  Pourquoi faire un sequence plot avec geom_point ? Il aurait bien mieux valu utiliser un histogramme pour comparer les distributions et voir la répartition des valeurs.

  Votre conclusion est la bonne par contre: "Les autres varient avce plus ou moins d’amplitude mais au finalement elle on toute une moyenne de 1".

• Q2
  

  "Cette aumgentation avoisine l’exponentielle." No comment. Enfin, si, vous ne savez visiblement pas ce qu'est une exponentielle. :)

  Erm. pour cette question, je vous renvoie à ce que j'ai dit à Mesnier et Morisson puisque vous avez fait la même analyse et les mêmes erreurs.

• Q3
  

  Pareil, allez voir ce que j'ai écrit pour Mesnier et Morison. Ce sont les mêmes erreurs. Je n'aime pas ça. Mais au moins, vous, vous avez remarqué qu'il y avait quelque chose de surprenant pour gamma(0.2,5) et pmtn_reset. Dans tous les cas, ce qui manque, c'est l'interprétation.

Anthony Leonard & Jérémy Hamerer: http://rpubs.com/leonaran/65254

• Q1
  

  Mettre toutes les lois sur le même graphe est une bonne idée. Par contre, cette représentation ne permet pas de bien voir comment se répartissent les différentes valeurs. Il aurait bien mieux valu utiliser un histogramme qu'un sequence plot. C'est dommage en fait car vous avez justement dessiné la distribution de loi gamma. Pourquoi n'avez vous pas fait pareil pour les autres lois ?

• Q2
  
  • Il aurait fallu borner le temps de réponse. C'était bien trop élevé de toutes façons pour que ça ait du sens.
  • Du coup quand vous dites "On constate que les temps de réponse sont similaires ainsi que leurs variabilités pour les politiques non préemptive, préemptive avec réinitialisation et préemptive avec reprise.", vous n'en savez rien. C'est trop petit pour que vous puissiez être sûrs. Regardez le corrigé.
• Q3
  

  Même problème que précédemment. Si vous ne bornez pas les ordonnées, les graphes sont illisibles.

  Vos analyses sont cependant correctes malgré ce handicap!!!

Luc Libralesso, Olivier Soldano: http://rpubs.com/librallu/dm1-ep

• Q1
  

  L'idée de supprimer les 200 premières tâches est intéressante. Vous dites que c'est pour améliorer la variance. Avez-vous vérifié si vous observiez une différence? Si ça "améliorait" effectivement les choses?

  • Votre étude des distribution est très bien. Juste une petite remarque, je ne suis pas sûr que les couleurs soient très utiles dans l'histogramme.
• Q2
  

  Nickel. Petite remarque, c'est outlier, pas outsider. :)

  L'utilisation de l'échelle log pour mieux voir est une bonne idée, même si ici, il vaut mieux restreindre l'échelle. En effet, quand les valeurs de temps de réponse sont trop grande, cela signifie que:

  1. le système n'est pas stable et la valeur mesurée n'a pas de sens, elle ne correspond pas à ce que vous souhaitez (l'espérance n'est pas forcément définie et la valeur finie que vous calculez n'a pas de sens car les temps de réponse des dernières tâche correspondent à une situation où vous avez arrêté d'injecter des tâches…);
  2. personne n'utiliserait un système avec un tel temps de réponse et d'autres phénomènes surviendraient (swap, client quittant le système, …) donc le modèle n'a plus grand sens de toutes façons;

  Dans ce cas, il vaut donc mieux borner arbitrairement les ordonnées.

  En ce qui concerne votre analyse, restart est effectivement très mauvaise pour les raisons que vous évoquées. Les autres ont un comportement similaire et pour cause. Lors d'un reset, comme la loi exponentielle est sans mémoire, si un nouveau temps est tiré c'est exactement comme le cas de pmtn. Il n'y a aucune différence entre ces trois politiques en raison des propriétés de la loi exponentielle.

• Q3
  

  Nickel. Vous avez effectivement compris comment ça marchait.

Romain Barthelemy & Malek Mammar: http://rpubs.com/Patator/65102

• Q1
  

  Pas mal. La représentation en sequence plot n'est cependant pas la meilleure pour comparer des distributions. Votre dernier graph (avec le geom_bar et les gros points rouges) qui représente la moyenne et la variance est par contre une très bonne idée.

• Q2
  

  Mais pourquoi tester des paramètre différents de la loi exponentielle pour le temps de service ? Ça n'a plus aucun sens, même si vous avez effectivement compris ce que cela signifiait (accélérer ou ralentir le serveur).

  Et surtout, avec une simulation aussi longue et pmtn_restart qui explose très vite, il fallait absolument borner les ordonnées. En effet, le système est saturé, emmagasine les tâches et une fois que toutes les 10,000 tâches sont arrivées, les relargue les unes après les autres. Les valeurs ainsi mesurées ne sont absolument pas représentatives du temps de traitement.

  Je ne sais pas trop quoi penser de votre étude du nombre d'interruption en fonction du débit d'arrivée.

• Q3
  

  Enfin, vous zoomez! :) Parfois, vos analyses sont trop focalisées sur la comparaison des courbes plus que sur ce qu'elles mettent en valeur. Par exemple, quand vous dites à propos de reset "Quand le délai inter arrivée est très faible (lambda tend vers 1), si le temps de service a tendance à être grand alors on se rapproche de la courbe du restart." En fait, ce qu'il se passe, c'est que le système devient saturé.

  Vous avez globalement effectivement compris ce qu'il se passait avec reset et restart et pourquoi reset s'en sortait de mieux en mieux quand la variance du temps de service était très grande. Vous avez aussi compris que j'attendais plus de texte (d'analyse) que de code… C'est bien. :)

Quentin Torck, Xueyong QIAN: http://rpubs.com/xuey90/64905

• Q1
  

  Vous avez des phrases qui ne se terminent pas. Genre "Dans un second temps nous tracerons les courbes précedente sur des".

  Vous n'avez absolument pas compris à quoi correspondait les paramètres des différentes loi et ce que vous avez étudié par la suite n'a aucun sens. Je prend un exemple. Vous faites:

  service2=Service(40,typeservice = "uni",id,id)
  

  Ça correspond à générer 40 temps de services uniformément distribués entre id et id… autrement dit égaux à id. Quel sens donnez-vous à ceci ?

  Sinon, vous ne pouvez pas dire qu'une évolution est exponentielle (" le temps d’éxecution pour le service 3 est exponentielle") à partir du moment où une fonction croit plus vite que d'autres…

  Le reste de l'analyse n'a hélas pas grand sens. ;(

• Q2
  

  Concernant votre problème de compilation, pas facile de dire avec un bout de code mal mis en forme mais quand je l'ai recopié, réindenté et remplacé les guillemets utf8 par des guillemets classique, je n'avais pas de problème de compilation.

EUDES Robin, ROSSI Ombeline: http://rpubs.com/Eudesr/64883

• Q1
  

  L'intérêt de cette question était de vérifier que vos appels à ces lois étaient cohérents, i.e., que vous utilisez des paramètres permettant d'avoir un temps de service moyen de 1 et de réaliser que ces lois différaient par leur variance.

• Q1
  

  Du coup, vous n'avez pas réalisé qu'en mettant x=0.5, vous simuliez un serveur capable de traiter 0.5 tâches par unité de temps et pas 1. Du coup, vous saturez votre système très rapidement et les valeurs que vous calculez lorsque vous injectez 0.8 tâches par unité de temps n'ont juste aucun sens… :(

• Q3
  

  Pareil là, mais pourquoi ??? Quand vous faites:

    res <- rbind(res,FileLIFO(n=1000,lambda=lambda_seq[i],typeservice="gamma1",x=1,y=1/lambda_seq[i],policy="npmtn"))
  

  En faisant ça, vous modifiez la variance du temps de service en fonction du taux d'arrivée… Ça n'a aucun sens. :( Du coup, le reste des analyses et des courbes non plus. :(

Leonard & Hammerrer

Thibault SAUSSAC & Sébastien TOUSSAINT

Vincent Mesnier & Jake Morison

Robin Eudes & Ombeline Rossi (http://rpubs.com/Eudesr/71305)

Guo Kai & Yao Longfei

Mammar & Barthelemy

Qian & Torck

Luc Libralesso - Olivier Soldano

  waiting <<- waiting[-which(waiting == running)]

Éric Michel Fotsing