Réunion des développeurs I2P - 22 mars 2005

13:01 <@jrandom> 0) salut 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) regroupement (batching) 13:01 <@jrandom> 3) mise à jour 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) salut 13:01 * jrandom fait signe de la main 13:01 <@jrandom> les notes d'état hebdomadaires viennent d'être publiées ici @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> salut 13:02 <+cervantes> ’lo 13:02 <@jrandom> on attaque direct avec 1) 0.5.0.3 13:02 <@jrandom> la version est sortie il y a quelques jours et les retours sont positifs 13:02 <+cervantes> jrandom: préviens-nous quand des nains bleus dansants montent sur ton écran et on écourtera la réunion 13:03 <@jrandom> heh cervantes 13:03 <@jrandom> (merci Bob pour les journaux de réunion éditables ;) 13:04 <@jrandom> je n’ai pas grand-chose à ajouter sur 0.5.0.3 par rapport à ce qui est dans ce message 13:04 <@jrandom> des commentaires/questions/inquiétudes à ce sujet ? 13:04 <bla> jrandom: De nouvelles mesures sur le code de sélection de pairs rapides ? 13:05 <@jrandom> ah, je savais qu’il y avait autre chose dans 0.5.0.3 que j’avais négligée ;) 13:06 <@jrandom> je n’ai pas encore de métriques solides, mais de façon anecdotique la sélection de pairs rapides a trouvé les pairs que je sais explicitement être « rapides » (par ex. des routers sur la même machine, etc.) 13:07 <bla> jrandom: Parfois, les eepsites nécessitent encore plusieurs tentatives pour trouver un tunnel utilisable 13:07 <@jrandom> des rapports indiquent aussi des débits assez raisonnables à l’occasion (dans la plage 10–20KBps), mais ce n’est pas encore fréquent (nous avons encore les paramètres réglés à la baisse) 13:08 <+ant> <Connelly> oups, il y a une réunion 13:09 <@jrandom> hmm, oui, j’ai constaté que la fiabilité n’est pas encore au niveau. Réessayer plus d’une fois n’est pas une solution — si un site ne se charge pas après 1 nouvel essai, laissez 5–10 m avant de réessayer 13:09 <@jrandom> ce que j’ai vu sur le réseau, ce sont des pics de latence au niveau de la couche de transport, pas assez rares 13:10 <@jrandom> par ex. 5–20+ secondes juste pour purger un message de 1–2KB à travers un socket 13:10 <@jrandom> ajoutez à ça un chemin à 5 sauts (tunnels à 2 sauts) et ça peut poser problème 13:11 <@jrandom> c’est d’ailleurs en partie ce qui motive le code de regroupement (batching) — réduire le # de messages à envoyer 13:13 <@jrandom> ok, quelqu’un d’autre a des questions/commentaires/inquiétudes sur 0.5.0.3 ? 13:13 <bla> jrandom: Ça a l’air bon. J’en demanderai plus dans la prochaine « section » 13:14 <@jrandom> w3rd, ok, on peut peut-être passer à 2) regroupement (batching) 13:15 <@jrandom> le mail et mon blog (jrandom.dev.i2p</spam>) devraient décrire les bases de ce qui est prévu 13:15 <@jrandom> et, bon, c’est vraiment des choses assez basiques 13:15 <@jrandom> le préprocesseur actuel que nous avons était le plus simple possible à implémenter (nom de classe : TrivialPreprocessor) ;) 13:16 <@jrandom> le nouveau a quelques paramètres réglables pour la fréquence de regroupement (batching), ainsi qu’une certaine affinité de tunnel sortant au sein des pools de tunnels individuels (où nous essayons de sélectionner le même tunnel sortant pour les requêtes suivantes pendant, par ex., jusqu’à 500 ms, afin d’optimiser le regroupement) 13:17 <@jrandom> c’est à peu près tout ce que j’ai à ajouter là-dessus — des questions/commentaires/inquiétudes ? 13:18 <bla> Est-ce que cela exige que tous les nœuds participants utilisent le nouveau préprocesseur, ou bien un mélange Trivial/NewOne peut-il coexister ? 13:18 <+Ragnarok> ça ajoutera 0,5 s à la latence, non ? 13:19 <@jrandom> bla: non, ce préprocesseur n’est utilisé que sur la tunnel gateway, et c’est à cette gateway de décider comment ou si elle regroupe 13:20 <@jrandom> Ragnarok: pas en général — le message 1 peut être retardé jusqu’à 0,5 s, mais les messages 2–15 sont transférés bien plus vite qu’ils ne l’auraient été autrement. C’est aussi un simple seuil — dès qu’un plein tunnel message de données est disponible, c’est vidé 13:20 <+Ragnarok> cool 13:20 <+Ragnarok> ça économise combien de surcharge ? 13:21 <@jrandom> considérable ;) 13:21 <+Ragnarok> considérable c’est bien, même si c’est vague :P 13:21 <@jrandom> regarde ton http://localhost:7657/oldstats.jsp#tunnel.smallFragments 13:21 <@jrandom> compare ça à #tunnel.fullFragments 13:22 <bla> jrandom: Cela ne concerne que la communication endpoint->IB-gateway ? 13:22 <@jrandom> avec le regroupement (batching), le ratio de full à small va augmenter, et le # d’octets de remplissage (pad bytes) dans les small va diminuer 13:23 <@jrandom> bla: hmm, ça concerne toutes les tunnel gateways, entrantes ou sortantes 13:24 <mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: ok 13:24 <mihi> can there be a frational number of fragments? 13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events 13:25 <@jrandom> heh mihi 13:25 <@jrandom> (ce small: 746 signifie que sur ces 692 k messages, 746 sur 996 octets étaient des octets de remplissage (pad bytes) « gaspillés » !) 13:26 <@jrandom> enfin, pas tout à fait gaspillés — ils avaient leur utilité 13:26 <+detonate> surcharge inutile quand même 13:27 <@jrandom> oui, dont une bonne partie qu’on devrait pouvoir éliminer avec le préprocesseur de regroupement (batching) 13:28 <@jrandom> malheureusement, ça ne sera pas inclus dans la prochaine version 13:28 <@jrandom> mais ce sera inclus dans la révision 0.5.0.6 (ou peut-être 0.5.1) 13:28 <@jrandom> euh, 0.5.0.5, ou 0.5.1 13:28 * jrandom se mélange les pinceaux avec les # 13:29 <bla> jrandom: Pourquoi pas ? 13:29 <+cervantes> hash et pilules... zut 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: il y a un bug dans la 0.5.0.3 (et avant) où le gestionnaire de messages fragmentés fera que les fragments suivants au sein du même tunnel message seront ignorés 13:31 <@jrandom> si on déployait le préprocesseur de regroupement (batching) directement, on aurait un nombre substantiel de messages perdus 13:31 <@jrandom> pas d’inquiétude, on a d’autres trucs sympas en réserve, donc la prochaine 0.5.0.4 ne sera pas totalement ennuyeuse ;) 13:31 <bla> jrandom: Ah, donc 13:32 <bla> jrandom: Ah, donc c’est pour ça qu’on doit faire ça après que 0.5.0.4 soit généralisée.. Je vois. Merci. 13:33 <@jrandom> oui, ce serait bien si le gestionnaire de fragments pouvait gérer ça, et en général il le fait, il libère juste le tampon d’octets trop tôt, annulant les fragments suivants (oups) 13:33 <@jrandom> ok, autre chose sur 2), ou on passe à 3) mise à jour ? 13:35 <@jrandom> ok, comme mentionné dans les notes d’état (et discuté depuis un moment dans divers endroits), nous allons ajouter des fonctionnalités pour une mise à jour simple et sûre qui ne requiert pas que l’utilisateur final aille sur le site, lise la mailing list ou lise le topic dans le canal :) 13:36 <+detonate> cool 13:36 <@jrandom> smeghead a assemblé du code pour aider à automatiser et sécuriser le processus, en travaillant avec cervantes pour l’intégrer à fire2pe ainsi qu’au routerconsole normal 13:37 <@jrandom> le mail liste la description générale de ce qui sera disponible, et bien que la plupart soit fonctionnel, il reste quelques morceaux pas encore totalement finalisés 13:37 <@jrandom> contrairement au regroupement (batching), cela /sera/ disponible dans la prochaine révision, même si les gens ne pourront pas en tirer grand-chose avant la 0.5.0.5 (quand il faudra mettre à jour) 13:39 <+Ragnarok> alors... c’est quoi les trucs sympas pour 5.0.4, du coup ? 13:42 <@jrandom> avec le code de mise à jour vient la possibilité de récupérer des annonces, affichant par ex. un extrait de news en haut de la router console. En plus de ça, dans le cadre du code de mise à jour nous avons un nouveau composant de téléchargement fiable qui fonctionne soit directement soit via l’eepproxy, en réessayant et en continuant en cours de route. Il y aura peut-être des fonctionnalités liées construites dessus, mais sans promesse 13:42 <+Ragnarok> sympa 13:43 <@jrandom> ok, quelqu’un d’autre a des questions/commentaires/inquiétudes sur 3) mise à jour ? 13:45 <@jrandom> sinon, on passe à 4) ??? 13:45 <@jrandom> autre chose que quelqu’un veut aborder ? je suis sûr d’avoir manqué des trucs 13:45 <+detonate> i2p est connu pour fonctionner avec la Sun JVM sous OpenBSD 3.7 :) 13:45 <@jrandom> nice! 13:47 <bla> Quel est le statut du transport UDP ? 13:48 <+detonate> l’udp va être désordonné, je pense qu’il vaudrait mieux voler le code de pipelining de bt et l’adapter ;) 13:48 <@jrandom> *tousse* 13:49 <@jrandom> je ne m’attends pas à beaucoup de problèmes, mais il y a certainement du travail 13:49 <@jrandom> la façon dont la politique de mise en file d’attente opère, ainsi que la limitation de bande passante (throttling) pour l’admission dans la file, seront intéressantes 13:50 <bla> Qui faisait ce travail préliminaire ? 13:50 <@jrandom> bla: detonate et mule 13:50 <+detonate> ouais.. je me suis relâché le mois dernier toutefois 13:50 <bla> detonate: Je suppose que tu plaisantes, avec ta remarque sur BT ? 13:51 <+detonate> je suis à moitié sérieux 13:51 <+detonate> on pourrait au moins diviser par deux le nombre de threads pour le transport si on faisait ça 13:51 * jrandom lance un seau de boue sur detonate 13:51 <jdot> ouais ! mon router tourne maintenant sur mon serveur dédié plutôt que sur ma connexion câble pourrie. 13:51 <@jrandom> bien joué jdot 13:52 <@jrandom> on pourra s’en sortir avec 3–5 threads dans la couche de transport pour toutes les comm avec tous les pairs 13:52 <bla> detonate: Mais la moitié ne suffira pas quand le réseau deviendra grand (> quelques centaines de nœuds) 13:52 <jdot> avec 1000GB de b/w à disposition 13:53 <jdot> malheureusement j.i2p et chat.i2p seront indisponibles encore quelques heures pendant que je migre les choses 13:53 <duck> detonate: addressbook en pause aussi ? 13:53 <+detonate> ouais, c’est en pause aussi 13:54 <+detonate> la seule chose qui n’est pas en pause est le stockage monolithique des profils, je comptais faire marcher ça plus tard aujourd’hui 13:54 <@jrandom> w3rd 13:54 <+detonate> alors I2P ne fragmentera pas le disque massivement 13:54 <jdot> jrandom: pour les limites de BP, ce sont des moyennes ? 13:54 <+frosk> les systèmes de fichiers modernes ne fragmentent pas, voyons 13:55 <+detonate> NTFS, si 13:55 <@jrandom> jdot: les limites de bande passante sont des seaux de jetons stricts (token buckets) 13:55 <@jrandom> jdot: si tu définis la durée de rafale, c’est la période sur laquelle ça fait la moyenne 13:56 <@jrandom> (bon, 2x burst == period) 13:56 <@jrandom> ((à peu près)) 13:56 <jdot> hmmm... eh bien j’ai 1000GB et je veux qu’i2p puisse prendre jusqu’à 800GB/mo.... 13:56 <+ant> <mihi> detonate: ntfs stocke les très petits fichiers dans la MFT, ce qui signifie presque pas de fragmentation 13:57 <jdot> et je me fiche du niveau des rafales 13:57 <+detonate> eh bien, quand tu lances le défragmenteur, il passe 10 minutes à déplacer les 6000 profils... donc ça doit fragmenter 13:58 <@jrandom> jdot: hmm, eh bien, 800GB c’est probablement plus que ce que ça voudra pousser de toute façon, donc tu peux probablement te passer de limites ;) 13:58 <@jrandom> d’un autre côté, si tu peux décrire une politique que tu voudrais voir implémentée, on pourrait peut-être la gérer 13:58 <jdot> jrandom: je vais faire ça pour l’instant et voir comment ça marche 13:58 <bla> detonate: NTFS, si je me souviens bien (IIRC), est un système de fichiers journalisé. Donc même un fichier monolithique se fragmentera si tu écris de petites portions dedans 13:58 <+detonate> tout est écrit d’un coup 13:59 <+detonate> et lu d’un coup 13:59 <bla> detonate: Ok. Je vois. 13:59 <jdot> jrandom: eh bien, attendons de voir si ce sera même un problème. 13:59 <bla> detonate: Bon travail dans ce cas ! 13:59 <+detonate> je serais curieux de savoir quel usage réel il y a si tu laisses sans limite 14:00 <+detonate> sur une bonne connexion 14:00 <jdot> moi aussi je suis curieux ! 14:00 <@jrandom> mes routers en colo tournent sans limite, mais sont contraints par le CPU 14:00 <+Ragnarok> peux-tu utiliser un bitbucket pour moyenner sur un mois ? 14:00 <jdot> jrandom: CPU contraint ? quel type de CPU ? 14:01 <@jrandom> transfert sur 4 j 3.04GB/2.73GB 14:01 <+detonate> hmm, je m’attendais à moins 14:01 <@jrandom> jdot: CPU contraint parce que j’y fais tourner 3 routers, plus quelques autres JVM, parfois avec profilage 14:01 <+detonate> ça doit être ces gens de bt 14:01 <+detonate> une fois le regroupement (batching) en place, ce serait intéressant de voir comment ça change 14:02 <@jrandom> detonate: une partie de ce trafic, c’est aussi moi qui pousse des fichiers de 50MB entre lui-même ;) 14:02 <+detonate> heh 14:02 <jdot> ahh. ok. eh bien, on va voir comment cette machine s’en sort. c’est un AMD XP 2400 avec 512MB et une connexion 10Mbit 14:02 <@jrandom> Ragnarok: les token buckets ne fonctionnent pas vraiment comme ça 14:02 <@jrandom> jdot: word, ouais, ici c’est un p4 1.6 iirc 14:03 <@jrandom> Ragnarok: dans un token bucket, chaque (par ex.) seconde tu ajoutes des jetons, selon le débit. si le seau est plein (taille = période de rafale), les jetons sont jetés 14:04 <@jrandom> chaque fois que tu veux transférer des données, tu dois obtenir une quantité suffisante de jetons 14:04 <@jrandom> (1 token = 1 octet) 14:04 <+Ragnarok> Je sais comment ça marche... que se passe-t-il si tu rends le seau très grand ? 14:05 <+detonate> alors tu n’arrêtes jamais d’envoyer des données 14:05 <+detonate> s’il est de taille infinie 14:05 <+detonate> euh, et qu’il est rempli de jetons 14:05 <@jrandom> s’il est vraiment grand, il peut se mettre à faire des rafales à débit illimité après une période de faible usage 14:06 <@jrandom> ce qui est peut-être souhaité dans certains cas 14:07 <@jrandom> le truc, c’est que tu ne peux pas simplement régler le token bucket à 800GB, car ça ne contraint pas la quantité totale transférée 14:08 <+detonate> il te faut un champ où tu peux définir le nombre de jetons par seconde, ensuite tu peux simplement diviser la bande passante mensuelle par le nombre de secondes 14:08 <+detonate> :) 14:10 <@jrandom> c’est pareil que fixer simplement le débit moyen sur le mois, ce qui serait déséquilibré. Mais bon, beaucoup de scénarios sont possibles — si quelqu’un en a qui répondent à ses besoins et qui ne peuvent pas être satisfaits avec ce qui existe, contactez-nous 14:10 <+Ragnarok> mais si tu fixes le débit à la moyenne voulue... je pense à 308 kB/s ici, puis que tu règles le bitbucket très grand... pourquoi ça ne marche pas ? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> eh bien, tu pourrais le régler pour qu’il n’envoie jamais plus de 800GB/44000 dans une période de rafale de 60 secondes 14:12 <+detonate> 44000 étant à peu près le nombre de minutes dans un mois 14:13 <@jrandom> la taille du seau / la durée de rafale décrit combien on enverra sans contrainte, et la plupart des gens veulent /vraiment/ des contraintes, pour que le router ne dévore pas 10mbps pendant 5 minutes en vidant le seau (ou autre) 14:14 <@jrandom> un étranglement supplémentaire (throttle) des jetons sortant du seau est aussi possible (et est-ce que cet étranglement devrait avoir son propre token bucket, et ce seau son propre étranglement, etc.) 14:16 <+Ragnarok> je pensais que le seau n’était rempli que quand la bande passante n’était pas utilisée 14:16 <@jrandom> les jetons sont ajoutés au seau à un débit constant (p. ex. 64k jetons par seconde) 14:17 <@jrandom> tout ce qui veut de la bande passante s’adresse toujours au seau 14:18 <+Ragnarok> ah.. ok 14:19 <@jrandom> ok cool, quelqu’un d’autre a quelque chose à aborder pour la réunion ? 14:21 <@jrandom> ok sinon 14:21 * jrandom se prépare 14:21 * jrandom *baf* ferme la réunion