Recapitulação rápida

Presentes: green, jrandom

Registro da Reunião

16:09 <jrandom> 0) oi 16:09 <jrandom> 1) Estado da rede 16:09 <jrandom> 2) Status do Syndie 16:09 <jrandom> 3) ??? 16:09 <jrandom> 0) oi 16:09 * jrandom acena 16:10 <jrandom> notas semanais de status publicadas em http://dev.i2p.net/pipermail/i2p/2006-May/001285.html 16:11 <jrandom> ok, enquanto vocês leem aquele e-mail empolgante, vamos direto para 1) Estado da rede 16:13 <jrandom> até agora, parece que toda a questão de colapso por congestionamento foi corrigida, e as taxas de criação de tunnel estão indo muito bem. ainda há questões a serem resolvidas 16:14 <jrandom> o comportamento cíclico discutido anteriormente (frequentemente em intervalos de 10-12 minutos) ainda está presente, causando rejeições de forma inversa. há uma nova correção no código a partir da -1 que deve se livrar disso, porém 16:15 <jrandom> (ou seja, randomizar as expirações de tunnel /corretamente/, ao contrário da randomização quebrada de antes) 16:16 <jrandom> isso, mais o agendamento aprimorado de ssu e de testes de tunnel, deve ajudar, mas em que grau, ainda não tenho total certeza 16:17 <jrandom> ok, isso é tudo o que tenho sobre isso no momento. alguém tem perguntas/comentários/preocupações sobre 1) Estado da rede? 16:18 <green> humm, os limites máximos de largura de banda nunca são alcançados e isso está bem longe do anterior 16:18 <green> como na 1-7 16:18 <green> s/1-7/.12-7 16:18 <jrandom> como está configurada a sua porcentagem de compartilhamento de largura de banda? isso agora é um controle muito poderoso 16:19 <green> 80% 16:19 <green> mas apenas cerca de 40% da largura de banda total é usada 16:20 <green> este é apenas um "do nothing router" :P 16:20 <jrandom> hmm, com que frequência sua largura de banda atinge picos de 80%, e você costuma rejeitar solicitações de tunnel (http://localhost:7657/oldstats.jsp#tunnel.reject.30 e tunnel.reject.*) 16:21 <jrandom> a periodicidade observada nas solicitações de tunnel frequentemente leva as pessoas a detectarem sobrecarga quando ela não está realmente ali 16:21 <jrandom> (porque routers têm capacidade excedente em outros momentos, só não quando estão sofrendo picos) 16:22 <green> tunnel.reject.30 é bem plano, tipo 1,00 ao longo de 14 025,00 eventos 16:22 <jrandom> ah, desculpa, o que importa é a própria contagem de eventos dessa estatística — você rejeitou mais de 14.000 solicitações de tunnel por sobrecarga de largura de banda 16:23 <jrandom> (o "valor" dessa estatística é quantos tunnels foram rejeitados no evento, e isso é sempre 1, já que um evento é causado por uma mensagem) 16:27 <jrandom> ok, se não há mais nada em 1) Estado da rede, vamos passar para 2) Status do Syndie 16:27 <jrandom> Não tenho muito mais a acrescentar ao que está no e-mail sobre o Syndie, só queria dar uma atualização 16:28 <jrandom> ok, sendo assim, a menos que alguém queira trazer algo à tona em relação ao Syndie, vamos pular para a velha de guerra, 3) ??? 16:28 <jrandom> alguém tem mais alguma coisa que queira trazer para a reunião? 16:31 * tethra gostaria de dizer "obrigado" (de novo) pelo .17, pois foi muita melhoria 16:33 <jrandom> feliz em ajudar, e tem mais coisas a caminho 16:33 <jrandom> ok, mas se não há mais nada para a reunião de hoje... 16:33 * jrandom vai encerrando 16:33 * jrandom *baf* encerra a reunião