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

<cervantes> moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html <cervantes> 0) hola <cervantes> 1) jrandom no está aquí <cervantes> 2) ??? <cervantes> 0) hola <cervantes> hola <cervantes> pasando al 1) <cervantes> jrandom no está aquí hoy, pero mañana nos dará una actualización de estado <cervantes> 2) ??? <cervantes> ¿alguien tiene algo más que añadir a la reunión? <bar> tengo una pregunta <cervantes> en ese caso... * cervantes se prepara * cervantes deja de prepararse <Complication> Ajá, una pregunta... <bar> la corrección del PRNG en cvs, ¿mejorará el rendimiento general o está relacionada con otra cosa? <cervantes> es incierto qué consecuencias podría tener en general <Complication> Personalmente no conozco su impacto total, pero sí implica al menos dos comportamientos que conozco: <cervantes> pero corrige específicamente un síntoma con i2ptunnel * cervantes deja que Complication descomplique <Complication> aleatorización de la longitud de tunnel y elección de servidor IRC (más genéricamente, selección aleatoria de una lista de destinos de I2PTunnel) <Complication> La aleatorización de la longitud de tunnel probablemente tenga un efecto significativo en la salud general de la red, ya que permite que los clientes a los que se les permite comprometer la longitud del tunnel realmente lo hagan <Complication> Así no estarán conteniendo la respiración y construyendo tunnels de 2 saltos, sino que también probarán algunos de 1 salto <Complication> (que en tiempos difíciles son mucho más fáciles de conseguir) <cervantes> además, la conectividad IRC podría mejorar una vez que se despliegue. Básicamente, freshcoffee nunca recibía conexiones de clientes porque estaba segundo en la lista; así que con la próxima versión la carga debería distribuirse uniformemente entre ambos servidores <bar> ¿entonces el bug hacía que la gente siempre optara por longitudes de tunnel más largas si estaban disponibles? <Complication> Si entendí bien, toda aleatorización con enteros pequeñitos (p. ej., elegir 0 o 1) se veía afectada <Complication> Creo que las aleatorizaciones con enteros más grandes (p. ej., elegir un entero entre 0 y 100) se veían menos afectadas <Complication> si te interesa, probablemente debas preguntar a jranom por detalles cuando vuelva <Complication> Puedo estar equivocándome en los detalles. <bar> ya veo, gracias. buen hallazgo <Complication> bueno, cervantes vino aquí y empezó a quejarse de no recibir nada de sobrecarga ;P <cervantes> esa era también mi impresión <cervantes> mira... no consigues nada en la vida si no refunfuñas :) <cervantes> ¿alguien más tiene otras preguntas o temas para la reunión? <fox> <duck> sí <Pi> una pregunta sobre la salud general de la red: veo que cada vez más clientes se quedan atrás en cuanto a versión de i2p (2 todavía usando 0.6.1.11 y así). ¿no harán estos clientes que monitorear los efectos de los cambios en el núcleo sea cada vez más difícil? (ya que "menos" parecen querer actualizar) <fox> * duck repite lo anterior * w423412323 sugiere un cambio de tema en esa línea. ;) <fox> <duck> Me preguntaba, he visto unos commits de ajuste curiosos en la lista de correo de cvs. ¿son más experimentos? ¿están basados en observaciones? ¿son prematuros? <Complication> Pi: mientras no estén presentes en grandes números, no deberían marcar mucha diferencia <Pi> 70 de 300 clientes usando una versión distinta de 0.6.1.18 según mi netdb ahora <Complication> Es un juego de números y capacidad: si o bien la mayoría de los routers, o además los routers de mayor capacidad están razonablemente actualizados, que algunas personas olviden que instalaron I2P no debería importar :) <cervantes> Pi: si los routers más antiguos se comportan mal, la red debería adaptarse y reducir el tráfico que se enruta a través de ellos <cervantes> *siendo enrutado <cervantes> Complication: ¿viste la pregunta de duck? <Pi> y una pregunta sobre una estadística en la i2p-console que apareció hace algún tiempo: ¿qué significa handle backlog? <Complication> duck: ¿te refieres a los ajustes de limitación (throttle) de tunnel? Son ajustes en el sentido de que no aportarán mucho inherentemente nuevo, pero deberían estar bastante bien probados ya (p. ej., probablemente no morderán) <Complication> Pero podrían morder un poco si ejecutas una configuración exótica que esté completamente fuera de los parámetros que pude imaginar <fox> <duck> Complication: me preguntaba si eso de '2' en lugar de '3' cositas realmente importaba tanto <fox> <duck> pero parecía que el problema de aleatoriedad podría haber sido un problema gordo <fox> <duck> (aunque el impacto relativo de eso en la mala salud de la red depende de cuándo se introdujo) <cervantes> Pi: handle backlog es el número de solicitudes pendientes de unión a tunnels entrantes (citado del changelog) <Complication> Si te refieres al problema con random nextInteger(), y al efecto en la aleatorización de la longitud de los tunnel, creo que tendría un efecto significativo <Complication> La diferencia de coste entre construir un tunnel de 1 salto y uno de 2 saltos es bastante significativa <Pi> gracias, cervantes :) <fox> <duck> ¿cuándo se introdujo? <Complication> duck: creo que se introdujo con algunos cambios al generador Fortuna, o alguna modificación en él <fox> <duck> ok; muchas gracias por tu aporte <Complication> Déjame consultar el cvsweb para más detalles... <cervantes> Pi: creo que ahora hay código que descarta solicitudes entrantes de tunnel si la cola se llena (para ayudar a reducir la carga de CPU) <Complication> Pi: sí, eso debería ser el indicador visible de otro parámetro usado para decidir "¿tenemos suficiente capacidad para participar en otro tunnel?" <cervantes> duck: sin duda noto un gran cambio en el comportamiento del router desde que se introdujo la corrección. - no todo bueno, hay que decirlo :) <Complication> handle backlog grande == congestión, no tiene sentido intentar unirse a los tunnels de otras personas <cervantes> tuve un promedio de carga de 14 y 12000 tunnels participantes el otro día <Complication> Handle backlog parece importante particularmente en routers de alta capacidad (refiriéndome a lo que vio cervantes) <Complication> Los routers de baja capacidad generalmente limitan su aceptación de tunnel por razones de ancho de banda <Complication> (o por razones de tiempo de prueba de tunnel, para ser correctos) <Complication> (o al menos, lo intentan) <cervantes> vaya, hemos llegado a media hora.... <Complication> En efecto :D <cervantes> ¿alguien quiere poner algo más sobre la mesa? <cervantes> en ese caso... * cervantes se prepara * cervantes *baffs* la reunión por cerrada <fox> <duck> gracias por ocuparte de la reunión <cervantes> jeje esperaba cerrarla con un baf antes de que nadie dijera nada.... pero bar arruinó ese plan :)