Reunião de Desenvolvedores do I2P - 22 de março de 2005

13:01 <@jrandom> 0) oi 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) batching 13:01 <@jrandom> 3) atualização 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) oi 13:01 * jrandom acena 13:01 <@jrandom> as notas semanais de status acabaram de ser postadas em http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> oi 13:02 <+cervantes> olá 13:02 <@jrandom> vamos direto para 1) 0.5.0.3 13:02 <@jrandom> o release saiu há alguns dias e os relatos têm sido positivos 13:02 <+cervantes> jrandom: avise quando os anões azuis dançantes subirem no seu monitor e a gente encerra a reunião mais cedo 13:03 <@jrandom> heh cervantes 13:03 <@jrandom> (agradeçam ao Bob pelos logs de reunião editáveis ;) 13:04 <@jrandom> não tenho muito a acrescentar em relação a 0.5.0.3 além do que está naquela mensagem 13:04 <@jrandom> alguém tem comentários/perguntas/preocupações sobre isso? 13:04 <bla> jrandom: Alguma nova medição no código de seleção de peers rápidos? 13:05 <@jrandom> ah, eu sabia que havia mais alguma coisa em 0.5.0.3 que eu tinha esquecido ;) 13:06 <@jrandom> ainda não tenho métricas firmes, mas anedoticamente a seleção de peers rápidos encontrou os peers que eu sei explicitamente serem “rápidos” (por exemplo, routers na mesma máquina, etc.) 13:07 <bla> jrandom: Às vezes, eepsites ainda exigem várias tentativas para encontrar um bom tunnel para usar 13:07 <@jrandom> também chegaram relatos de taxas de transferência razoáveis em algumas ocasiões (na faixa de 10-20KBps), mas isso ainda não é frequente (ainda mantemos os parâmetros reduzidos) 13:08 <+ant> <Connelly> opa, tem reunião 13:09 <@jrandom> hmm, sim, notei que a confiabilidade ainda não está onde precisa estar. refazer mais de uma tentativa realmente não é solução — se um site não carregar após 1 nova tentativa, espere de 5 a 10 min antes de tentar de novo 13:09 <@jrandom> o que tenho visto na rede são alguns picos de atraso na camada de transporte com frequência não tão baixa 13:10 <@jrandom> por exemplo, levar 5–20+ segundos só para escoar uma mensagem de 1–2KB por um socket 13:10 <@jrandom> some isso a um caminho de 5 saltos (tunnels de 2 saltos) e você pode ter problemas 13:11 <@jrandom> isso na verdade é parte do que está impulsionando o código de batching — reduzir o nº de mensagens a serem enviadas 13:13 <@jrandom> ok, mais alguém tem perguntas/comentários/preocupações sobre 0.5.0.3? 13:13 <bla> jrandom: Parece bom. Vou perguntar mais sobre isso na próxima “seção” 13:14 <@jrandom> w3rd, ok, talvez possamos avançar então — 2) batching 13:15 <@jrandom> o e-mail e meu blog (jrandom.dev.i2p</spam>) devem descrever o básico do que está planejado 13:15 <@jrandom> e, bem, na verdade são coisas bem básicas 13:15 <@jrandom> o pré-processador atual que temos foi o mais simples possível de implementar (nome da classe: TrivialPreprocessor) ;) 13:16 <@jrandom> o novo tem alguns parâmetros ajustáveis para a frequência de batching, bem como alguma afinidade de tunnel de saída dentro de pools de tunnel individuais (onde tentamos selecionar o mesmo tunnel de saída para solicitações subsequentes por até, por exemplo, 500 ms, para podermos otimizar o batching) 13:17 <@jrandom> é praticamente isso que tenho a acrescentar — alguma pergunta/comentário/preocupação? 13:18 <bla> Isso exige que todos os nós participantes executem o novo pré-processador, ou um mix de Trivial/NewOne pode coexistir? 13:18 <+Ragnarok> isso vai adicionar 0,5 s à latência, certo? 13:19 <@jrandom> bla: não, esse pré-processador é usado apenas no tunnel gateway (ponto de entrada/saída do tunnel) e cabe a esse gateway decidir como ou se vai agrupar 13:20 <@jrandom> Ragnarok: normalmente não — a mensagem 1 pode ser atrasada em até 0,5 s, mas as mensagens 2–15 são transferidas muito mais rápido do que seriam. também é um limiar simples — assim que houver dados suficientes para encher uma mensagem de tunnel inteira, ela é escoada 13:20 <+Ragnarok> legal 13:20 <+Ragnarok> quanto overhead isso economiza? 13:21 <@jrandom> bastante ;) 13:21 <+Ragnarok> bastante é bom, embora vago :P 13:21 <@jrandom> olhe em http://localhost:7657/oldstats.jsp#tunnel.smallFragments 13:21 <@jrandom> compare com #tunnel.fullFragments 13:22 <bla> jrandom: Isso diz respeito apenas à comunicação endpoint->IB-gateway? 13:22 <@jrandom> com batching, a razão de full para small vai subir, e o nº de bytes de preenchimento nos small vai cair 13:23 <@jrandom> bla: hmm, diz respeito a todos os tunnel gateways, sejam inbound ou outbound 13:24 <mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: ok 13:24 <mihi> pode haver um número fracional de fragmentos? 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> (esse small: 746 significa que nessas 692k mensagens, 746 de 996 bytes foram bytes de preenchimento desperdiçados!) 13:26 <@jrandom> bem, não completamente desperdiçados — cumpriram seu propósito 13:26 <+detonate> overhead desnecessário de qualquer forma 13:27 <@jrandom> sim, muito do qual devemos conseguir eliminar com o pré-processador de batching 13:28 <@jrandom> infelizmente, isso não será incluído no próximo release 13:28 <@jrandom> mas será incluído na revisão 0.5.0.6 (ou talvez 0.5.1) 13:28 <@jrandom> erm, 0.5.0.5, ou 0.5.1 13:28 * jrandom fica confuso com os números 13:29 <bla> jrandom: Por que não? 13:29 <+cervantes> haxixe e pílulas... droga 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: há um bug no 0.5.0.3 (e anteriores) em que o manipulador de mensagens fragmentadas faz com que fragmentos subsequentes dentro da mesma mensagem de tunnel sejam descartados 13:31 <@jrandom> se implantássemos o pré-processador de batching diretamente, teríamos um número substancial de mensagens perdidas 13:31 <@jrandom> sem estresse, temos outras coisas legais na manga, então este próximo 0.5.0.4 não vai ser totalmente entediante ;) 13:31 <bla> jrandom: Ah, então é isso 13:32 <bla> jrandom: Ah, então é por isso que temos que fazer isso depois que 0.5.0.4 estiver disseminado... Entendi. Valeu. 13:33 <@jrandom> sim, seria bom se o manipulador de fragmentos conseguisse lidar com isso, e ele consegue, em geral, só que libera o buffer de bytes cedo demais, zerando os fragmentos subsequentes (ops) 13:33 <@jrandom> ok, mais algo em 2), ou partimos para 3) atualização? 13:35 <@jrandom> ok, como mencionado nas notas de status (e discutido há um tempo em vários locais), vamos adicionar alguma funcionalidade para atualização simples e segura que não exija que o usuário final vá ao site, leia a lista de e-mails ou leia o tópico no canal :) 13:36 <+detonate> legal 13:36 <@jrandom> smeghead montou algum código para ajudar a automatizar e proteger o processo, trabalhando com o cervantes para integrar ao fire2pe bem como ao routerconsole normal 13:37 <@jrandom> o e-mail lista a descrição geral do que vai estar disponível e, embora a maior parte esteja funcional, ainda há algumas partes não totalmente definidas 13:37 <@jrandom> diferente do batching, isso /vai/ estar disponível na próxima revisão, embora as pessoas não consigam fazer muito uso até o 0.5.0.5 (quando chegar a hora de atualizar) 13:39 <+Ragnarok> então... quais são as coisas legais do 5.0.4, então? 13:42 <@jrandom> com o código de atualização vem a capacidade de puxar dados de anúncio, exibindo, por exemplo, um trecho de notícias no topo do router console. além disso, como parte do código de atualização temos um novo componente de download confiável que funciona diretamente ou através do eepproxy, refazendo tentativas e continuando pelo caminho. talvez haja alguns recursos relacionados construídos a partir disso, mas sem promessas 13:42 <+Ragnarok> bacana 13:43 <@jrandom> ok, mais alguém tem perguntas/comentários/preocupações sobre 3) atualização? 13:45 <@jrandom> se não, passando para 4) ??? 13:45 <@jrandom> mais alguma coisa que alguém queira levantar? tenho certeza de que deixei algumas coisas de fora 13:45 <+detonate> i2p está funcionando com a Sun JVM no OpenBSD 3.7 :) 13:45 <@jrandom> legal! 13:47 <bla> Qual é o status do transporte UDP? 13:48 <+detonate> udp vai ser bagunçado, acho melhor roubar o código de pipelining do bt e adaptá-lo ;) 13:48 <@jrandom> *cof* 13:49 <@jrandom> não espero muitos problemas, mas certamente há trabalho a ser feito 13:49 <@jrandom> como a política de enfileiramento opera, bem como a limitação de largura de banda para admissão à fila, será interessante 13:50 <bla> Quem estava fazendo aquele trabalho preliminar? 13:50 <@jrandom> bla: detonate e mule 13:50 <+detonate> sim.. tenho estado largado no último mês mais ou menos 13:50 <bla> detonate: Presumo que esteja brincando com seu comentário sobre BT? 13:51 <+detonate> meio sério 13:51 <+detonate> você ao menos poderia reduzir pela metade a contagem de threads do transporte se fizesse isso 13:51 * jrandom atira um balde de lama no detonate 13:51 <jdot> uhuu. meu router agora está rodando no meu servidor dedicado em vez da minha conexão de cabo porcaria. 13:51 <@jrandom> nice1 jdot 13:52 <@jrandom> vamos conseguir nos virar com 3–5 threads na camada de transporte para toda a comunicação com todos os peers 13:52 <bla> detonate: Mas metade não vai resolver quando a rede ficar grande (> algumas centenas de nós) 13:52 <jdot> com 1000GB de largura de banda à disposição 13:53 <jdot> infelizmente j.i2p e o chat.i2p vão ficar fora do ar por mais algumas horas enquanto eu migro as coisas 13:53 <duck> detonate: addressbook também está parado? 13:53 <+detonate> sim, também está parado 13:54 <+detonate> a única coisa que não está parada é o armazenamento monolítico de perfis, eu tinha intenção de fazê-lo funcionar mais tarde hoje 13:54 <@jrandom> w3rd 13:54 <+detonate> assim o i2p não fragmenta o disco massivamente 13:54 <jdot> jrandom: quanto aos limites de largura de banda, são médias? 13:54 <+frosk> sistemas de arquivos modernos não fragmentam, bobagem 13:55 <+detonate> ntfs fragmenta 13:55 <@jrandom> jdot: os limites de largura de banda são strict token buckets 13:55 <@jrandom> jdot: se você definir a duração da rajada, esse é o período pelo qual a taxa é calculada em média 13:56 <@jrandom> (bem, 2x a rajada == período) 13:56 <@jrandom> ((mais ou menos)) 13:56 <jdot> hmmm... bem, eu tenho 1000GB e quero que o i2p possa consumir até 800GB/mês.... 13:56 <+ant> <mihi> detonate: ntfs armazena arquivos muito pequenos no mft, o que significa quase nenhuma fragmentação 13:57 <jdot> e não me importo com o que estourar 13:57 <+detonate> bem, quando você roda o desfragmentador, ele passa 10 minutos movendo todos os 6000 perfis... então devem fragmentar 13:58 <@jrandom> jdot: hmm, bem, 800GB provavelmente é mais do que ele vai querer enviar de qualquer forma, então você provavelmente pode ficar sem limites ;) 13:58 <@jrandom> por outro lado, se você puder descrever uma política que gostaria que fosse implementada, talvez possamos atendê-la 13:58 <jdot> jrandom: vou fazer isso por enquanto e ver como funciona 13:58 <bla> detonate: NTFS, se bem me lembro, é um FS com journalling. Então até um arquivo monolítico vai fragmentar se você escrever pequenas porções nele 13:58 <+detonate> tudo é escrito de uma vez só 13:59 <+detonate> e lido de uma vez só 13:59 <bla> detonate: Ok. Entendi. 13:59 <jdot> jrandom: bem, vamos esperar até vermos se isso vai mesmo ser um problema. 13:59 <bla> detonate: Bom trabalho nesse caso! 13:59 <+detonate> eu teria interesse em saber quanto uso realmente há se você deixar sem limite 14:00 <+detonate> em uma conexão boa 14:00 <jdot> eu também estou interessado! 14:00 <@jrandom> meus routers em colocation rodam sem limite, embora limitados por CPU 14:00 <+Ragnarok> dá para usar um bitbucket para fazer a média ao longo de um mês? 14:00 <jdot> jrandom: limitado por cpu? que tipo de cpu? 14:01 <@jrandom> transferência em 4d 3.04GB/2.73GB 14:01 <+detonate> hmm, esperava menos 14:01 <@jrandom> jdot: limitado por CPU porque rodo 3 routers nele, além de algumas outras JVMs, às vezes fazendo profiling 14:01 <+detonate> deve ser aquele pessoal do bt 14:01 <+detonate> quando o lance de batching estiver online, seria interessante ver como isso muda 14:02 <@jrandom> detonate: parte dessa transferência também sou eu empurrando arquivos de 50MB entre si ;) 14:02 <+detonate> heh 14:02 <jdot> ahh. ok. bem, vamos ver como esse sistema se sai. é um AMD XP 2400 com 512MB e uma conexão de 10Mbit 14:02 <@jrandom> Ragnarok: token buckets não funcionam bem assim 14:02 <@jrandom> jdot: certo, sim, este é um p4 1.6 iirc 14:03 <@jrandom> Ragnarok: em um token bucket, a cada (por exemplo) segundo você adiciona alguns tokens, de acordo com a taxa. se o balde estiver cheio (tamanho = duração da rajada), os tokens são descartados 14:04 <@jrandom> sempre que você quiser transferir dados, precisa obter uma quantidade suficiente de tokens 14:04 <@jrandom> (1 token = 1 byte) 14:04 <+Ragnarok> Eu sei como funcionam... o que acontece se você simplesmente tornar o balde muito grande? 14:05 <+detonate> então você nunca para de enviar dados 14:05 <+detonate> se for infinito em tamanho 14:05 <+detonate> err, e estiver cheio de tokens 14:05 <@jrandom> se for muito grande, pode sair por aí e estourar para taxas ilimitadas após pouco uso 14:06 <@jrandom> embora talvez isso seja desejado em alguns casos 14:07 <@jrandom> a questão é que você não pode simplesmente definir o token bucket para 800GB, pois isso não restringiria o total transferido 14:08 <+detonate> você precisa de um campo ali onde possa definir o número de tokens por segundo, então dá para simplesmente dividir o uso de largura de banda por mês pelo número de segundos 14:08 <+detonate> :) 14:10 <@jrandom> isso é o mesmo que apenas definir a taxa média ao longo do mês, o que ficaria desbalanceado. mas, enfim, há muitos cenários possíveis — se alguém tiver algum que atenda às suas necessidades e que não possa ser atendido com o que há, por favor, entre em contato 14:10 <+Ragnarok> mas se você definir a taxa para a média que quer... acho que 308 kB/s aqui, e então definir o bitbucket para algo bem maior... por que isso não funciona? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> bem, você poderia definir para nunca enviar mais de 800GB/44000 em um período de rajada de 60 segundos 14:12 <+detonate> 44000 sendo aproximadamente o número de minutos em um mês 14:13 <@jrandom> o tamanho do balde / duração da rajada descreve quanto enviaremos sem restrição, e a maioria das pessoas /quer/ restrições, para o router não abocanhar 10mbps por 5 minutos enquanto esvazia o balde (ou o que for) 14:14 <@jrandom> um limitador adicional de tokens saindo do balde também é possível (e esse limitador deveria ter seu próprio token bucket, e esse balde seu próprio limitador, etc.) 14:16 <+Ragnarok> Eu achava que o balde só recebia quando havia largura de banda não utilizada 14:16 <@jrandom> tokens são adicionados ao balde a uma taxa constante (por exemplo, 64k tokens por segundo) 14:17 <@jrandom> qualquer coisa que queira largura de banda sempre pede ao balde 14:18 <+Ragnarok> ah.. ok 14:19 <@jrandom> ok, legal, mais alguém tem algo que queira trazer para a reunião? 14:21 <@jrandom> ok, se não 14:21 * jrandom se prepara 14:21 * jrandom encerra a reunião com um *baf*