Réunion des développeurs I2P - 16 mai 2006

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) salut <cervantes> 1) jrandom n'est pas là <cervantes> 2) ??? <cervantes> 0) salut <cervantes> salut <cervantes> passons au point 1) <cervantes> jrandom n'est pas là aujourd'hui, mais il nous fera un point d'avancement demain <cervantes> 2) ??? <cervantes> quelqu'un a autre chose à ajouter à la réunion ? <bar> j'ai une question <cervantes> dans ce cas... * cervantes s'échauffe * cervantes arrête de s'échauffer <Complication> Ah, une question... <bar> la correction PRNG dans cvs, est-ce que ça améliorera les performances générales ou est-ce lié à autre chose ? <cervantes> on ne sait pas trop quelles conséquences ça pourrait avoir en général <Complication> je ne connais pas personnellement tout son impact, mais cela touche au moins deux comportements dont je suis au courant : <cervantes> mais cela corrige spécifiquement un symptôme avec i2ptunnel * cervantes laisse Complication décompliquer <Complication> randomisation de la longueur du tunnel et choix du serveur IRC (plus généralement, sélection aléatoire à partir d'une liste de destinations I2PTunnel) <Complication> La randomisation de la longueur du tunnel a probablement un effet significatif sur la santé globale du réseau, puisqu'elle permet aux clients qui sont autorisés à faire des compromis sur la longueur du tunnel de réellement le faire <Complication> Ainsi, ils ne resteront pas en apnée à construire des tunnels à 2 sauts, mais essayeront aussi des tunnels à 1 saut <Complication> (qui, en période difficile, sont beaucoup plus faciles à obtenir) <cervantes> la connectivité irc pourrait aussi s'améliorer une fois que ce sera déployé. En gros, freshcoffee ne recevait jamais de connexions client parce qu'il était deuxième dans la liste - donc avec la prochaine version la charge devrait être répartie équitablement entre les deux serveurs <bar> donc le bug faisait toujours choisir aux gens des longueurs de tunnel plus grandes si disponibles ? <Complication> Si j'ai bien compris, toute randomisation avec de petits entiers (par ex. choisir 0 ou 1) était affectée <Complication> Je *pense* que les randomisations avec de plus grands entiers (par ex. choisir un entier entre 0 et 100) étaient moins affectées <Complication> si ça t'intéresse, tu devrais probablement demander des détails à jranom quand il sera de retour <Complication> il se peut que je me trompe dans les détails. <bar> je vois, merci. bien vu <Complication> eh bien, cervantes est venu ici et a commencé à se plaindre de ne pas avoir de surcharge ;P <cervantes> c'était aussi ma compréhension <cervantes> tu vois... on n'obtient rien dans la vie si on ne râle pas :) <cervantes> quelqu'un a d'autres questions ou sujets pour la réunion ? <fox> <duck> oui <Pi> une question sur la santé générale du réseau : je vois de plus en plus de clients rester à la traîne côté version i2p (2 utilisent encore 0.6.1.11 et ainsi de suite). ces clients ne vont-ils pas rendre de plus en plus difficile le suivi des effets des changements sur le coeur ? (puisque "moins nombreux" semblent vouloir mettre à jour) <fox> * duck répète ci-dessus * w423412323 suggère un changement de sujet dans cette veine. ;) <fox> <duck> Je me demandais, j'ai vu des commits d'ajustement un peu funky sur la liste de diffusion cvs. ce sont plutôt des expériences ? ils sont basés sur des observations ? ils sont prématurés ? <Complication> Pi : tant qu'ils ne sont pas présents en grand nombre, ils ne devraient pas faire une grande différence <Pi> 70 sur 300 clients utilisent une version non-0.6.1.18 d'après mon netdb maintenant <Complication> C'est une question de nombres et de capacité - si soit la plupart des routers, soit en plus les routers à plus forte capacité sont raisonnablement à jour, quelques personnes qui oublient qu'elles ont installé I2P ne devraient pas poser problème :) <cervantes> Pi : si les routers plus anciens se comportent mal, le réseau _devrait_ s'adapter et réduire le trafic routé via eux <cervantes> *routé <cervantes> Complication : as-tu vu la question de duck ? <Pi> et une question à propos d'une stat sur la i2p-console apparue il y a quelque temps : que signifie handle backlog ? <Complication> duck : tu veux dire les ajustements de limitation de débit des tunnels ? Ce sont des réglages dans le sens où ils n'apportent pas grand-chose de vraiment nouveau, mais ils devraient être maintenant assez bien testés (par ex. ils ne devraient probablement pas mordre) <Complication> Mais ils pourraient mordre un peu, si tu fais tourner une configuration exotique complètement en dehors des paramètres auxquels j'aurais pu penser <fox> <duck> Complication : je me demandais si les bidules '2' au lieu de '3' comptaient vraiment tant que ça <fox> <duck> mais il semblait que le problème de random pouvait avoir été un gros méchant <fox> <duck> (bien que l'impact relatif de cela sur la mauvaise santé du réseau dépende du moment où ça a été introduit) <cervantes> Pi : handle backlog est le nombre de demandes en attente de jonction de tunnel entrantes (citation du changelog) <Complication> Si tu parles du problème de random nextInteger(), et de l'effet sur la randomisation de la longueur du tunnel, je pense que cela aurait un effet significatif <Complication> La différence de coût entre construire un tunnel à 1 saut et à 2 sauts est assez significative <Pi> merci, cervantes :) <fox> <duck> quand cela a-t-il été introduit ? <Complication> duck : je pense que cela a été introduit avec certains basculements vers le générateur Fortuna, ou une modification dedans <fox> <duck> ok; merci beaucoup pour tes éclairages <Complication> Laisse-moi vérifier le cvsweb pour plus de détails... <cervantes> Pi : je crois qu'il y a maintenant du code en place qui rejette les requêtes de tunnel entrantes si la file se remplit (pour aider à réduire la charge cpu) <Complication> Pi : oui, cela devrait être l'indicateur visible d'un autre paramètre utilisé pour décider "avons-nous assez de capacité pour participer à un autre tunnel ?" <cervantes> duck : j'ai certainement constaté un grand changement dans le comportement du router depuis l'introduction du correctif. - pas que du bon, je dois dire :) <Complication> gros handle backlog == congestion, aucun intérêt à essayer de rejoindre les tunnels des autres <cervantes> j'ai eu un load average de 14 et 12000 tunnels participants l'autre jour <Complication> Le handle backlog semble important particulièrement sur les routers à haute capacité (en référence à ce qu'a vu cervantes) <Complication> Les routers de faible capacité limitent généralement leur acceptation de tunnel pour des raisons de bande passante <Complication> (ou pour des raisons de temps de test de tunnel, pour être exact) <Complication> (ou du moins, essaient de le faire) <cervantes> waouh, on a tenu une demi-heure.... <Complication> En effet :D <cervantes> quelqu'un veut ajouter autre chose à l'ordre du jour ? <cervantes> dans ce cas... * cervantes s'échauffe * cervantes *baffe* la réunion pour la clore <fox> <duck> merci d'avoir pris en charge la réunion <cervantes> heh je m'attendais à la baffer fermée avant que qui que ce soit ne dise quoi que ce soit....mais bar a ruiné ce plan :)