Reunión de desarrolladores de I2P - 02 de mayo de 2006

16:09 <jrandom> 0) hola 16:09 <jrandom> 1) Estado de la red 16:09 <jrandom> 2) Estado de Syndie 16:09 <jrandom> 3) ??? 16:09 <jrandom> 0) hola 16:09 * jrandom saluda 16:10 <jrandom> notas semanales de estado publicadas en http://dev.i2p.net/pipermail/i2p/2006-May/001285.html 16:11 <jrandom> bien, mientras todos leen ese emocionante correo, pasemos a 1) Estado de la red 16:13 <jrandom> hasta ahora, parece que todo el problema de colapso por congestión está arreglado, y las tasas de creación de tunnel van bastante bien. aun así, quedan problemas por resolver 16:14 <jrandom> el comportamiento cíclico del que hablamos antes (a menudo en intervalos de 10-12 minutos) sigue presente, causando rechazos de forma inversa. hay una nueva corrección en el código a partir de la -1 que debería eliminar eso 16:15 <jrandom> (a saber, aleatorizar las expiraciones de tunnel /correctamente/, a diferencia de la aleatorización rota de antes) 16:16 <jrandom> eso, más la programación mejorada de ssu y de pruebas de tunnel debería ayudar, pero en qué grado, no estoy del todo seguro aún 16:17 <jrandom> ok, eso es todo lo que tengo sobre eso por el momento. ¿alguien tiene preguntas/comentarios/preocupaciones sobre 1) Estado de la red? 16:18 <green> humm, los límites máximos de ancho de banda nunca se alcanzan y esto está muy lejos de lo anterior 16:18 <green> como en 1-7 16:18 <green> s/1-7/.12-7 16:18 <jrandom> ¿cómo está configurado tu porcentaje de compartición de ancho de banda? eso ahora es un control muy potente 16:19 <green> 80% 16:19 <green> pero solo se usa cerca del 40% del ancho de banda total 16:20 <green> esto es solo un "router que no hace nada" :P 16:20 <jrandom> hmm, ¿con qué frecuencia tus picos de ancho de banda llegan al 80%, y con qué frecuencia rechazas solicitudes de tunnel (http://localhost:7657/oldstats.jsp#tunnel.reject.30 y tunnel.reject.*) 16:21 <jrandom> la periodicidad que se ve en las solicitudes de tunnel a menudo hace que la gente detecte sobrecarga cuando en realidad no la hay 16:21 <jrandom> (porque los routers tienen capacidad extra en otros momentos, solo que no cuando están recibiendo picos) 16:22 <green> tunnel.reject.30 está muy plana, como 1,00 sobre 14 025,00 eventos 16:22 <jrandom> oh, perdón, lo clave para esa estadística es el propio recuento de eventos: has rechazado más de 14.000 solicitudes de tunnel por sobrecarga de ancho de banda 16:23 <jrandom> (el "valor" para esa estadística es cuántos tunnels se rechazaron en el evento, y eso siempre es 1, ya que un evento lo provoca un mensaje) 16:27 <jrandom> bien, si no hay nada más sobre 1) Estado de la red, pasemos a 2) Estado de Syndie 16:27 <jrandom> no tengo mucho más que añadir a lo que hay en el correo respecto a Syndie, solo quería dar una actualización 16:28 <jrandom> ok, así que, a menos que alguien quiera sacar algo a colación con respecto a Syndie, pasemos a la de siempre, 3) ??? 16:28 <jrandom> ¿alguien tiene algo más que quiera plantear para la reunión? 16:31 * tethra le gustaría decir "gracias" (otra vez) por la .17, ya que ha supuesto muchas mejoras 16:33 <jrandom> me alegra ayudar, y hay más cosas en camino 16:33 <jrandom> ok, pero si no hay nada más para la reunión de hoy... 16:33 * jrandom se prepara 16:33 * jrandom *baf* cierra la reunión