Reunião de Desenvolvedores do I2P - 07 de março de 2006

15:08 <jrandom> 0) oi 15:08 <jrandom> 1) Estado da rede 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) oi 15:08 * jrandom acena 15:08 <jrandom> notas semanais de status publicadas em http://dev.i2p.net/pipermail/i2p/2006-March/001267.html 15:09 * jrandom dá a vocês algumas horas para ler esse enorme tomo de notas 15:10 * Complication finge que ainda não percebeu ;) 15:11 <+Complication> Oi :) 15:11 <+susi23> oi :) 15:12 <jrandom> bem, vamos começar com 1) estado da rede 15:12 <jrandom> O e-mail dá minha visão geral do que está acontecendo. Como isso se alinha com o que vocês estão vendo? 15:13 <+Complication> As correções no throttling (controle de taxa) parecem ter aumentado a confiabilidade, mas realmente reduziram a largura de banda 15:13 <+Complication> Um segundo, procurando o gráfico 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> Os trechos altos são em versões não mais recentes; os trechos baixos, na mais recente 15:15 <+Complication> As mesmas configurações do limitador, possivelmente mais frouxas nas versões mais rígidas (as mais recentes) 15:16 <+Complication> Mas não é grande problema, já que transfere 15:16 <jrandom> legal, a redução no uso de largura de banda é apropriada à medida que você se aproxima do seu limite real de largura de banda 15:17 <+Complication> Na maior parte do tempo, parece recuar antes do limite de "largura de banda sustentada" 15:17 <+Complication> Nunca toca o limite de burst 15:18 <+Complication> (o que, por si só, faz sentido — o que me preocupa é recuar antes do limite sustentado) 15:19 <bar> estou vendo praticamente o que o Complication está vendo. meu consumo total de largura de banda é apenas 50% das minhas configurações máximas. costumava ser ~80% antes da 0.6.1.11 15:19 <jrandom> 200kbps é a sua taxa do limitador, c/ 300kbps de burst? 15:20 <jrandom> (só querendo saber quanto tempo costumava passar no burst) 15:20 <jrandom> a redução no uso de largura de banda, porém, é um dos objetivos das mudanças recentes 15:21 <+Complication> ~225 sustentado, ~325 burst 15:21 <+Complication> Ei, eu poderia ter... 15:22 <+Complication> Eu *interpretei* errado? 15:23 <+Complication> Esqueçam, fui bobo... fiz a conta errada, não é nem de longe tão ruim :O 15:23 <jrandom> dados insuficientes :) pode ser indicativo de um problema, mas o que você descreveu até agora sugere que as coisas estão se comportando como desejado 15:23 <+Complication> É um pouco conservador, mas nem de perto tão ruim quanto eu pensei 15:24 <+Complication> De acordo com a Router Console (que mede na mesma unidade do limitador), a média total de saída é 2/3 do limite sustentado e 1/2 do limite de burst 15:25 <+Complication> Mas a média total de entrada, tenho que dizer, está apenas um pouco acima de 1/3 do limite sustentado e 1/4 do limite de burst 15:26 <+Complication> por exemplo, assumindo um limite sustentado de 30 e um limite de burst de 40, a saída seria 20 e a entrada pouco acima de 10 (principalmente por falta de carga) 15:26 <jrandom> legal 15:26 <+Complication> Mas o gráfico eu interpretei mal, por causa de questões de Kb/KB :O 15:27 * Complication apaga o gráfico do histórico 15:28 <jrandom> bom olho, mesmo assim; com certeza me avise quando as coisas soarem esquisitas 15:28 <jrandom> ok, mais alguma coisa sobre 1) Estado da rede? 15:28 <jrandom> se não, vamos passar para 2) ??? 15:28 <jrandom> alguém tem mais algo para discutir? 15:30 <+Complication> Bem, houve alguns testes com o jbigi e, aparentemente, alguém obteve resultados que sugeriam que a versão de 64 bits para Linux estava meio lenta 15:31 <+Complication> Eles viram mais lento do que Java puro, não sei se foi falha de medição ou não :O 15:32 <+Complication> Eu não consegui repetir 15:32 <jrandom> sim, eu não tinha certeza de qual .so exatamente eles estavam usando para a plataforma 15:32 <+Complication> Aqui, foi cerca de duas vezes mais rápido que Java puro 15:32 <+dust> meus experimentos com HTML como formato adicional de mensagem no syndie estão começando a funcionar. meu 'sucker' local agora consegue recuperar páginas da web (com imagens) e armazená-las como posts do syndie 15:33 <jrandom> ah, maneiro, dust 15:33 <+dust> mas sem CSS 15:33 <+Complication> Mas pessoas em 32 bits falaram que era *bem* mais rápido que Java puro (tipo 10x ou algo assim) 15:35 <bar> hmm.. Complication, poderia ser que o .so amd64 atual seja apenas para sistemas de 32 bits e ele testou em um SO de 64 bits? 15:36 <+Complication> bar: pode ser, já que eu também testei em um SO de 64 bits :O 15:36 <jrandom> se não me engano, o amd64 foi compilado para funcionar no Debian pure64 15:37 <+Complication> De todo modo, algumas pessoas sugeriram que importar um gmp mais novo poderia ajudar 15:37 <bar> só um chute no escuro, não sou craque nessas coisas 15:37 <jrandom> eh, usamos 4.1.4 15:37 <+Complication> Especialmente depois que eles fizerem o salto de versão que está para sair 15:38 <+Complication> Como não sou especialista em gmp, não posso dizer muito sobre isso 15:38 <jrandom> (e as otimizações que estão por vir no gmp não devem trazer melhorias substanciais) 15:38 <+Complication> Além de "talvez mesmo" 15:38 <jrandom> as melhorias vêm de compilações específicas por arquitetura 15:40 <+Complication> No meu teste, provocado pelo teste deles, a biblioteca para Athlon 64 em um Sempron de 64 bits, num Mandriva de 64 bits... parece ser apenas marginalmente mais rápida que Java puro 15:40 <+Complication> (ah, e uma VM de 64 bits) 15:41 <+Complication> (marginalmente sendo o dobro) 15:41 <jrandom> hmm ok 15:42 <+Complication> Vou tentar testar em mais combinações de plataforma e avisar se eu encontrar algo que valha a pena relatar 15:43 <jrandom> legal, obrigado 15:43 <jrandom> ok, alguém tem mais algo para a reunião? 15:46 <jrandom> se não... 15:46 * jrandom se encaminha para encerrar 15:47 * jrandom fecha a reunião com um *baf*