Bref récapitulatif

Présents : green, jrandom

Journal de réunion

16:09 <jrandom> 0) salut 16:09 <jrandom> 1) État du réseau 16:09 <jrandom> 2) État de Syndie 16:09 <jrandom> 3) ??? 16:09 <jrandom> 0) salut 16:09 * jrandom fait coucou 16:10 <jrandom> notes d'état hebdomadaires publiées sur http://dev.i2p.net/pipermail/i2p/2006-May/001285.html 16:11 <jrandom> ok, pendant que vous lisez ce mail palpitant, passons à 1) État du réseau 16:13 <jrandom> jusqu'ici, il semble que tout le problème d'effondrement dû à la congestion soit corrigé, et les taux de création de tunnel se portent plutôt bien. il reste toutefois des problèmes à régler 16:14 <jrandom> le comportement cyclique évoqué précédemment (souvent sur des intervalles de 10 à 12 minutes) est toujours présent, provoquant des rejets de manière inverse. il y a un nouveau correctif dans le code depuis la -1 qui devrait s'en débarrasser 16:15 <jrandom> (à savoir, randomiser les expirations de tunnel /correctly/, contrairement à l'ancienne randomisation cassée) 16:16 <jrandom> ça, plus l'amélioration de la planification des tests ssu et de tunnel devrait aider, mais dans quelle mesure, je n'en suis pas encore tout à fait sûr 16:17 <jrandom> ok, c'est à peu près tout ce que j'ai pour le moment. quelqu'un a des questions/commentaires/inquiétudes à propos de 1) État du réseau ? 16:18 <green> humm, les limites max de bw ne sont jamais atteintes et on est vraiment loin d'avant 16:18 <green> comme en 1-7 16:18 <green> s/1-7/.12-7 16:18 <jrandom> à combien est réglé votre pourcentage de partage de bw ? c'est maintenant un contrôle très puissant 16:19 <green> 80% 16:19 <green> mais seulement environ 40% de la bw totale est utilisée 16:20 <green> c'est juste un router qui ne fait rien :P 16:20 <jrandom> hmm, à quelle fréquence votre bw grimpe-t-elle jusqu'à 80 %, et refusez-vous souvent des requêtes de tunnel (http://localhost:7657/oldstats.jsp#tunnel.reject.30 et tunnel.reject.*) 16:21 <jrandom> la périodicité observée dans les requêtes de tunnel amène souvent les gens à détecter une surcharge alors qu'elle n'est pas vraiment là 16:21 <jrandom> (parce que les routers ont de la capacité excédentaire à d'autres moments, juste pas quand ils subissent des pics) 16:22 <green> tunnel.reject.30 est très plat, comme 1,00 sur 14 025,00 événements 16:22 <jrandom> oh, désolé, c'est le nombre d'événements lui-même pour cette stat qui est clé - vous avez rejeté plus de 14 000 requêtes de tunnel à cause d'une surcharge de bande passante 16:23 <jrandom> (la "value" pour cette stat est le nombre de tunnel rejetés lors de l'événement, et c'est toujours 1, puisqu'un événement est causé par un message) 16:27 <jrandom> ok, s'il n'y a rien d'autre sur 1) État du réseau, passons à 2) État de Syndie 16:27 <jrandom> je n'ai pas grand-chose à ajouter à ce qui est dans l'email concernant syndie, je voulais juste donner une mise à jour 16:28 <jrandom> ok, donc, à moins que quelqu'un veuille soulever quelque chose concernant syndie, passons à la bonne vieille 3) ??? 16:28 <jrandom> quelqu'un a autre chose qu'il veut aborder pour la réunion ? 16:31 * tethra aimerait dire « merci » (encore) pour la .17, car ça a été une grosse amélioration 16:33 <jrandom> ravi d'aider, et il y a plus de choses en route 16:33 <jrandom> ok, mais s'il n'y a rien d'autre pour la réunion d'aujourd'hui... 16:33 * jrandom conclut 16:33 * jrandom *baf* clôt la réunion