Discussion:Round-robin (informatique)

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

- L’algorithme round-robin est il avec réquisition ou sans réquisition ?

- Dans le 2e exemple de cas problématique ("Si le quantum est de 4 ms et que le processus met 2 ms à s'exécuter, on perd 50 % du temps"), le pourcentage de temps perdu ne dépend-il pas aussi du temps que l'on met pour changer de processus ? Si on met aussi 1ms, alors 2ms d'exécution + 1ms de changement de contexte font que 3ms sur les 4 disponibles auront été utilisées. Ce qui ne laisse plus que 25% de temps perdu.

Bonjour,
Je m'interroge également sur ce paragraphe. Je pense que dans un cas réel, quand un processus a fini de s'exécuter avant la fin du temps imparti, il rends la main et le processeur est attribué à un autre processus. Ceci dit, si on considère le cas d'un algo RR bête qui ne change pas de processus avant la fin du temps imparti (4ms), alors on a 2ms d’exécution, 2ms d'attente, puis 1ms de changement de contexte, soit une perte de temps de (2+1)/(2+2+1)=60%.
De même, cette phrase de l'article me déplais : "Si le quantum est de 4 ms et qu'il faut 1 ms pour changer de processus, on perd donc 25 % du temps en changement". Si je comprends bien, on a 4ms d’exécution puis 1ms de changement de contexte, donc la perte de temps est de 1/(4+1)=20% (et non 1/4=25%). Je corrige l'article (-> "[...] on perd donc 1/(4+1) = 20 % du temps [...]").
JeromeJerome (d) 4 janvier 2013 à 16:40 (CET)[répondre]
Je pense aussi que le processus rapide va immédiatement rendre la main au système, donc j'ai quelques doutes sur la pertinence du second paragraphe (mais je ne suis pas expert). Par contre je peux dire qu'il y a un problème sur la logique (mathématiques) :
  • Le premier paragraphe explique que le temps de changement de contexte ne fait pas partie du temps disponible, donc le temps total est 4+1 et pas de 4 (on ne peut pas trouver 25%).
  • Le résultat de 33% qui était en ligne avant ma modification est faux (j'ai vu le calcul, mais je comprend même pas que son auteur à voulu calculer, ça n'a pas sens d'écrire 4+2 puisque le 2 fait partie intégrante du 4).
  • Maintenant la question est de savoir si on doit calculer avec le temps de changement de contexte (ce qui va donner 60%) ou pas (ce qui va donner 50%). Mais le but ici est de prouver que le quantum est trop long, donc inclure le temps de changement de contexte ne me parait pas pertinent ici. Donc j'ai préféré revenir au résultat d'origine (50%) en mettant de côté le temps de changement de processus qui n'est pas pertinent dans cette démonstration, étant donné ce qu'on cherche à prouver.
Melnofil (discuter) 23 mai 2024 à 03:00 (CEST)[répondre]

Inexactitudes[modifier le code]

  • Dans la section "Réseau" de l'article il est dit que "Chaque serveur traite le même nombre de requêtes." Cela n'est vrai qu'asymptotiquement. Étant donnée la spécification DNS lorsque le trafic est modeste la charge peut être tout à fait inégale. Il suffit qu'un gros ISP cache une des deux adresses pour que le trafic soit tout à fait inégal par exemple.
    • cf.http://en.wikipedia.org/wiki/Round_robin_DNS : "Although easy to implement, round robin DNS has problematic drawbacks, such as those arising from record caching in the DNS hierarchy itself, as well as client-side address caching and reuse, the combination of which can be difficult to manage. Round robin DNS should not solely be relied upon for service availability. If a service at one of the addresses in the list fails, the DNS will continue to hand out that address and clients will still attempt to reach the inoperable service".--Barrycarton (d) 8 août 2009 à 00:04 (CEST)[répondre]
Bonjour,

Je ne vois pas où est le problème ou l'inexactitude, dans cet article on ne parle pas load balancing de la charge d'un serveur DNS, mais de load balancing de charge en général, soit sur une ferme de serveurs, ce qui est dans le principe semblable mais pas exactement identique. Dans ce qui est dit : Round-robin est une répartition de charge (load balancing) équitable entre serveurs d'une ferme informatique (cluster). Chaque serveur traite le même nombre de requêtes. Cela nécessite une ferme de serveurs homogènes en capacité de traitement. Cette répartition de charge peut être effectuée par le serveur DNS (Domain Name System) qui associe plusieurs adresses IP à un nom de domaine.
Les requêtes ne sont pas des requêtes DNS qui ont pour but une "résolution de nom", ce sont des requêtes au sens générale (DNS, SQL, recherche de fichier, calcule complexe, rendu 3D, serveurs d'application,...) et c'est un serveur DNS qui a pour rôle de répartir la charge générée pas les demandeurs entre les différentes machines capables de répondre. Le DNS répartiteur utilise un algorithme Round-Robin pour répartir les demandes, donc - à une requête près - toutes les machines du cluster sont également chargées.

Cordialement
--2()®C-1L|ß& (d) 10 août 2009 à 12:38 (CEST)--[répondre]
Bonjour,
c'est tout à fait exact. Ma reserve c'est que quand on lit le la phrase "Cette répartition de charge peut être effectuée par le serveur DNS (Domain Name System) qui associe plusieurs adresses IP à un nom de domaine." dans le contexte on pourrait être amené à penser que la charge effective sur chaque node sera identique or c'est tout à fait faux en pratique. N'avez-vous pas cette impression en relisant la phrase? En gros ce que je voulais dire c'est que la charge est répartie de façon homogène par le / les serveurs DNS mais que la charge sur chaque noeud n'est pas homogène loin s'en faut. --Barrycarton (d) 11 août 2009 à 20:06 (CEST)[répondre]
Bonjour,
Dans cette explication on ne parle pas de la répartition de change entre diffèrent nœud (cluster), mais de la repartissions de charge entres les différentes machines d'un nœud (cluster), ce qui est diffèrent.
Je reformulerais ça une peut plus proprement d'ici une heure ou deux.
Cordialement
--2()®C-1L|ß& (d) 12 août 2009 à 09:39 (CEST)--[répondre]