Réunion des développeurs I2P - 7 mars 2006

15:08 <jrandom> 0) salut 15:08 <jrandom> 1) État du réseau 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) salut 15:08 * jrandom fait coucou 15:08 <jrandom> les notes d'état hebdomadaires sont publiées à http://dev.i2p.net/pipermail/i2p/2006-March/001267.html 15:09 * jrandom vous laisse des heures pour parcourir ce gros pavé de notes 15:10 * Complication fait semblant de ne pas avoir encore remarqué ;) 15:11 <+Complication> Salut :) 15:11 <+susi23> salut :) 15:12 <jrandom> bon, autant se plonger dans 1) état du réseau 15:12 <jrandom> Le mail donne mon point de vue général sur ce qui se passe. comment cela correspond-il à ce que vous voyez ? 15:13 <+Complication> Les correctifs de throttling (limitation) semblent avoir augmenté la fiabilité, mais ont vraiment réduit la bande passante 15:13 <+Complication> Une seconde, je cherche le graphique 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> Les périodes hautes sont sur des versions non à jour, les périodes basses sur les dernières 15:15 <+Complication> Mêmes paramètres du limiteur, possiblement plus laxistes sur les versions plus strictes (les dernières) 15:16 <+Complication> Mais ce n'est pas vraiment un problème, puisque ça transfère 15:16 <jrandom> cool, une réduction de l'utilisation de bande passante est appropriée lorsqu'on se rapproche de sa limite réelle de bande passante 15:17 <+Complication> La plupart du temps, ça semble revenir en arrière avant d'atteindre la "limite de bande passante soutenue" 15:17 <+Complication> N'atteint jamais la limite de rafale 15:18 <+Complication> (ce qui, en soi, est logique - c'est le fait de revenir en arrière avant la limite soutenue qui m'inquiète) 15:19 <bar> je vois à peu près la même chose que Complication. ma conso totale de bande passante n'est qu'à 50% de mes réglages max. avant 0.6.1.11 c'était ~80% 15:19 <jrandom> 200 kbps est-il ton débit du limiteur, avec 300 kbps en rafale ? 15:20 <jrandom> (je me demande juste combien de temps ça passait en mode rafale) 15:20 <jrandom> réduire l'utilisation de bande passante est toutefois l'un des objectifs des changements récents 15:21 <+Complication> ~225 soutenu, ~325 rafale 15:21 <+Complication> Hé, j'aurais pu... 15:22 <+Complication> Est-ce que je l'ai mal *interprété* ? 15:23 <+Complication> Laissez tomber, je suis idiot... j'ai mal fait le calcul, ce n'est pas si grave :O 15:23 <jrandom> données insuffisantes :) cela pourrait être l'indication d'un problème, mais ce que tu as décrit jusqu'ici suggère que les choses se comportent comme prévu 15:23 <+Complication> C'est un peu conservateur, mais pas aussi mauvais que je le pensais 15:24 <+Complication> Selon la Router Console (qui mesure dans la même unité que le limiteur), la moyenne totale sortante est à 2/3 de la limite soutenue, et à 1/2 de la limite de rafale 15:25 <+Complication> Mais la moyenne totale entrante, je dois dire, n'est qu'un peu au-dessus de 1/3 de la limite soutenue, et 1/4 de la limite de rafale 15:26 <+Complication> par exemple, en supposant une limite soutenue de 30 et une limite de rafale de 40, la sortie serait à 20 et l'entrée juste au-dessus de 10 (surtout par manque de charge) 15:26 <jrandom> cool 15:26 <+Complication> Mais le graphique, je l'ai mal interprété, à cause de soucis Kb/KB :O 15:27 * Complication efface le graphique de l'historique 15:28 <jrandom> bon œil quand même, n'hésitez pas à me prévenir quand quelque chose semble bizarre 15:28 <jrandom> ok, autre chose sur 1) État du réseau ? 15:28 <jrandom> si non, passons à 2) ??? 15:28 <jrandom> quelqu'un a autre chose à discuter ? 15:30 <+Complication> Eh bien, il y a eu des tests jbigi et, apparemment, quelqu'un a obtenu des résultats suggérant que la version 64 bits pour Linux était plutôt lente 15:31 <+Complication> Chez eux, c'était plus lent que le Java pur, je ne sais pas si c'est un bug de mesure ou pas :O 15:32 <+Complication> Je n'ai pas pu le reproduire 15:32 <jrandom> ouais, je n'étais pas sûr de quel .so exactement ils utilisaient pour la plateforme 15:32 <+Complication> Ici, c'était environ deux fois plus rapide que le Java pur 15:32 <+dust> mes expériences avec html comme format de message supplémentaire dans syndie commencent à fonctionner. mon 'sucker' local peut maintenant récupérer des pages web (avec images) et les stocker comme des billets syndie 15:33 <jrandom> ah excellent, dust 15:33 <+dust> pas de css par contre 15:33 <+Complication> Mais des gens en 32 bits disaient que c'était bien plus rapide que le Java pur (genre x10 ou approchant) 15:35 <bar> hmm.. Complication, se peut-il que le .so amd64 actuel soit uniquement pour systèmes 32 bits, et qu'il l'ait testé sur un OS 64 bits ? 15:36 <+Complication> bar: possible, puisque je l'ai testé moi aussi sur un OS 64 bits :O 15:36 <jrandom> si je me souviens bien l'amd64 a été compilé pour fonctionner sur Debian pure64 15:37 <+Complication> Quoi qu'il en soit, certains ont suggéré qu'importer un gmp plus récent pourrait aider 15:37 <bar> c'est juste un coup dans le noir, je ne suis pas un as dans ce domaine 15:37 <jrandom> eh, on utilise 4.1.4 15:37 <+Complication> Surtout après leur saut de version imminent 15:38 <+Complication> Comme je ne suis pas spécialiste de gmp, je ne peux pas en dire beaucoup 15:38 <jrandom> (et les optimisations à venir dans gmp ne devraient pas apporter d'amélioration substantielle) 15:38 <+Complication> À part "peut-être bien" 15:38 <jrandom> les améliorations viennent de compilations par architecture 15:40 <+Complication> Dans mon test, provoqué par leur test, la bibliothèque 64 bits pour Athlon sur un Sempron 64 bits, sous une Mandriva 64 bits, toutefois... ne semble que marginalement plus rapide que le Java pur 15:40 <+Complication> (oh, et une VM 64 bits) 15:41 <+Complication> ("marginalement" signifiant deux fois) 15:41 <jrandom> hmm ok 15:42 <+Complication> Je vais essayer de tester davantage de combinaisons de plateformes, et je dirai si je trouve quelque chose qui vaille la peine d'être relayé 15:43 <jrandom> cool, merci 15:43 <jrandom> ok, quelqu'un a autre chose pour la réunion ? 15:46 <jrandom> si non... 15:46 * jrandom termine 15:47 * jrandom *baf* clôt la réunion