Reunión de desarrolladores de I2P - 22 de marzo de 2005

13:01 <@jrandom> 0) hola 13:01 <@jrandom> 1) 0.5.0.3 13:01 <@jrandom> 2) agrupamiento 13:01 <@jrandom> 3) actualización 13:01 <@jrandom> 4) ??? 13:01 <@jrandom> 0) hola 13:01 * jrandom saluda con la mano 13:01 <@jrandom> las notas de estado semanales recién publicadas están disponibles en http://dev.i2p.net/pipermail/i2p/2005-March/000654.html 13:02 <+detonate> hola 13:02 <+cervantes> buenas 13:02 <@jrandom> vamos directo a 1) 0.5.0.3 13:02 <@jrandom> la versión salió hace unos días, y los informes han sido positivos 13:02 <+cervantes> jrandom: avísanos cuando los enanos azules bailarines se suban a tu monitor y terminamos la reunión antes 13:03 <@jrandom> je, cervantes 13:03 <@jrandom> (den gracias a Bob por los registros editables de la reunión ;) 13:04 <@jrandom> realmente no tengo mucho más que añadir con respecto a 0.5.0.3 aparte de lo que está en ese mensaje 13:04 <@jrandom> ¿alguien tiene comentarios/preguntas/inquietudes al respecto? 13:04 <bla> jrandom: ¿Alguna medición nueva sobre el código de selección de pares rápidos? 13:05 <@jrandom> ah, sabía que había algo más en 0.5.0.3 que había pasado por alto ;) 13:06 <@jrandom> aún no tengo métricas duras, pero de forma anecdótica la selección de pares rápidos ha encontrado los pares que sé explícitamente que son 'rápidos' (p. ej., routers en la misma máquina, etc.) 13:07 <bla> jrandom: A veces, las eepsites aún requieren varios reintentos para encontrar un buen tunnel que usar 13:07 <@jrandom> también han llegado informes de tasas de rendimiento bastante razonables en ocasiones (en el rango de 10–20 KBps), pero eso aún no es frecuente (todavía tenemos los parámetros ajustados a la baja) 13:08 <+ant> <Connelly> ups, hay una reunión 13:09 <@jrandom> hmm, sí, he visto que la fiabilidad aún no está donde debería. reintentar más de una vez realmente no es una solución; si un sitio no carga tras 1 reintento, dale 5–10 min antes de volver a intentar 13:09 <@jrandom> lo que sí he visto en la red son picos de retraso en la capa de transporte con una frecuencia nada despreciable 13:10 <@jrandom> p. ej., tardar de 5 a más de 20 segundos solo para vaciar un mensaje de 1–2 KB a través de un socket 13:10 <@jrandom> si a eso le sumas un recorrido de 5 saltos (tunnels de 2 saltos), puedes meterte en problemas 13:11 <@jrandom> eso de hecho es parte de lo que impulsa el código de agrupamiento: reducir la cantidad de mensajes a enviar 13:13 <@jrandom> ok, ¿alguien más tiene preguntas/comentarios/inquietudes sobre 0.5.0.3? 13:13 <bla> jrandom: Se ve bien. Preguntaré más sobre ello en la próxima «sección» 13:14 <@jrandom> w3rd, ok, quizá podamos pasar entonces a — 2) agrupamiento 13:15 <@jrandom> el correo y mi blog (jrandom.dev.i2p</spam>) deberían describir lo básico de lo planeado 13:15 <@jrandom> y, bueno, en realidad es algo bastante básico 13:15 <@jrandom> el preprocesador actual que tenemos fue el más simple posible de implementar (nombre de la clase: TrivialPreprocessor) ;) 13:16 <@jrandom> este nuevo tiene algunos parámetros ajustables para la frecuencia de agrupación, así como cierta afinidad de tunnel saliente dentro de pools de tunnel individuales (donde intentamos seleccionar el mismo tunnel saliente para solicitudes posteriores durante hasta, p. ej., 500 ms, de modo que podamos optimizar el agrupamiento) 13:17 <@jrandom> eso es más o menos todo lo que tengo que añadir sobre eso: ¿preguntas/comentarios/inquietudes? 13:18 <bla> ¿Esto requiere que todos los nodos participantes ejecuten el nuevo preprocesador, o puede coexistir una mezcla de Trivial/NewOne? 13:18 <+Ragnarok> esto añadirá 0,5 s a la latencia, ¿cierto? 13:19 <@jrandom> bla: nah, este preprocesador solo se usa en la puerta de enlace del tunnel, y depende de esa puerta de enlace decidir cómo o si agrupar 13:20 <@jrandom> Ragnarok: por lo general no: el mensaje 1 puede retrasarse hasta 0,5 s, pero los mensajes 2–15 se transfieren mucho más rápido de lo que lo harían de otro modo. también es un umbral simple: tan pronto como haya disponible datos equivalentes a un mensaje de tunnel completo, se vacía 13:20 <+Ragnarok> genial 13:20 <+Ragnarok> ¿cuánta sobrecarga ahorra? 13:21 <@jrandom> considerable ;) 13:21 <+Ragnarok> considerable está bien, aunque vago :P 13:21 <@jrandom> mira en tu http://localhost:7657/oldstats.jsp#tunnel.smallFragments 13:21 <@jrandom> compáralo con #tunnel.fullFragments 13:22 <bla> jrandom: ¿Esto concierne solo a la comunicación endpoint->IB-gateway? 13:22 <@jrandom> con el agrupamiento, la proporción de completos frente a pequeños subirá, y el n.º de bytes de relleno en los pequeños bajará 13:23 <@jrandom> bla: hmm, concierne a todas las puertas de enlace de tunnel, ya sean de entrada o de salida 13:24 <mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events 13:24 <bla> jrandom: ok 13:24 <mihi> ¿puede haber un número fraccional de fragmentos? 13:24 <@jrandom> completos: 1.00 sobre 807,077.00 eventos pequeños: 746.80 sobre 692,682.00 eventos 13:25 <@jrandom> je, mihi 13:25 <@jrandom> (ese «pequeños: 746» significa que, en esos 692k mensajes, ¡746 de 996 bytes eran bytes de relleno desperdiciados!) 13:26 <@jrandom> bueno, no del todo desperdiciados: cumplieron su función 13:26 <+detonate> en cualquier caso, sobrecarga innecesaria 13:27 <@jrandom> sí, y gran parte deberíamos poder eliminarla con el preprocesador de agrupamiento 13:28 <@jrandom> por desgracia, eso no se incluirá en la próxima versión 13:28 <@jrandom> pero se incluirá en la revisión 0.5.0.6 (o quizá 0.5.1) 13:28 <@jrandom> erm, 0.5.0.5, o 0.5.1 13:28 * jrandom se confunde con los #s 13:29 <bla> jrandom: ¿Cómo es que no? 13:29 <+cervantes> hachís y pastillas... maldita sea 13:30 <@jrandom> !thwap cervantes 13:30 <@jrandom> bla: hay un bug en 0.5.0.3 (y anteriores) en el que el manejador de mensajes fragmentados hará que se descarten los fragmentos posteriores dentro del mismo mensaje de tunnel 13:31 <@jrandom> si desplegáramos directamente el preprocesador de agrupamiento, tendríamos una cantidad considerable de mensajes perdidos 13:31 <@jrandom> no es preocupante; tenemos otras cosas interesantes bajo la manga, así que la próxima 0.5.0.4 no será totalmente aburrida ;) 13:31 <bla> jrandom: Ah, ya veo 13:32 <bla> jrandom: Ah, por eso tenemos que hacer eso después de que 0.5.0.4 sea mainstream... Entiendo. Gracias. 13:33 <@jrandom> sí, estaría bien que el manejador de fragmentos pudiera lidiar con ello, y en general lo hace; solo que libera el búfer de bytes demasiado pronto, poniendo a cero los fragmentos posteriores (ups) 13:33 <@jrandom> ok, ¿algo más sobre el punto 2), o pasamos al 3) actualización? 13:35 <@jrandom> ok, como se mencionó en las notas de estado (y se discutió durante un tiempo en diversos ámbitos), vamos a añadir funcionalidad para una actualización simple y segura que no requiera que el usuario final vaya al sitio web, lea la lista de correo o lea el topic en el canal :) 13:36 <+detonate> genial 13:36 <@jrandom> smeghead ha montado algo de código para ayudar a automatizar y asegurar el proceso, trabajando con cervantes para integrarlo con fire2pe así como con la routerconsole normal 13:37 <@jrandom> el correo enumera la descripción general de lo que va a estar disponible y, aunque la mayor parte es funcional, aún hay algunas piezas que no están completamente pulidas 13:37 <@jrandom> a diferencia del agrupamiento, esto sí estará disponible en la próxima rev, aunque la gente no podrá sacarle mucho partido hasta 0.5.0.5 (cuando toque actualizar) 13:39 <+Ragnarok> entonces... ¿cuáles son las cosas guays para 5.0.4? 13:42 <@jrandom> con el código de actualización llega la capacidad de traer datos de anuncios, mostrando, por ejemplo, un fragmento de noticias en la parte superior de la consola del router. además de eso, como parte del código de actualización tenemos un nuevo componente de descarga fiable que funciona directamente o a través del eepproxy, reintentando y continuando en el camino. quizá haya algunas funciones relacionadas construidas sobre eso, pero sin promesas 13:42 <+Ragnarok> qué bien 13:43 <@jrandom> ok, ¿alguien más tiene preguntas/comentarios/inquietudes sobre 3) actualización? 13:45 <@jrandom> si no, pasamos a 4) ??? 13:45 <@jrandom> ¿algo más que alguien quiera plantear? estoy seguro de que he pasado por alto algunas cosas 13:45 <+detonate> se sabe que I2P funciona con la JVM de Sun en OpenBSD 3.7 :) 13:45 <@jrandom> ¡bien! 13:47 <bla> ¿Cuál es el estado del transporte UDP? 13:48 <+detonate> UDP va a ser complicado; creo que sería mejor robar el código de pipelining de bt y adaptarlo ;) 13:48 <@jrandom> *cof* 13:49 <@jrandom> no espero que haya demasiados problemas, pero sin duda hay trabajo por hacer 13:49 <@jrandom> cómo opera la política de encolamiento, así como la limitación de ancho de banda para la admisión a la cola, será interesante 13:50 <bla> ¿Quién estaba haciendo ese trabajo preliminar? 13:50 <@jrandom> bla: detonate y mule 13:50 <+detonate> sí... he estado flojeando el último mes o así, eso sí 13:50 <bla> detonate: ¿supongo que bromeas, con tu comentario de BT? 13:51 <+detonate> lo digo a medias en serio 13:51 <+detonate> al menos podrías reducir a la mitad el número de hilos del transporte si hicieras eso 13:51 * jrandom arroja un cubo de lodo a detonate 13:51 <jdot> woohoo. mi router ahora está funcionando en mi servidor dedicado en lugar de en mi conexión por cable de mierda (POS). 13:51 <@jrandom> ¡bien ahí, jdot! 13:52 <@jrandom> podremos apañarnos con 3–5 hilos en la capa de transporte para toda la comunicación con todos los pares 13:52 <bla> detonate: pero la mitad no va a bastar cuando la red se haga grande (> un par de cientos de nodos) 13:52 <jdot> con 1000 GB de ancho de banda a su disposición 13:53 <jdot> por desgracia, j.i2p y chat.i2p estarán caídos unas horas más mientras migro las cosas 13:53 <duck> detonate: ¿addressbook en pausa también? 13:53 <+detonate> sí, también está en pausa 13:54 <+detonate> lo único que no está en pausa es el almacenamiento monolítico de perfiles; pensaba ponerlo a funcionar más tarde hoy 13:54 <@jrandom> w3rd 13:54 <+detonate> entonces I2P no fragmentará el disco de forma masiva 13:54 <jdot> jrandom: en lo que respecta a los límites de ancho de banda, ¿son promedios? 13:54 <+frosk> los sistemas de archivos modernos no fragmentan, tonto 13:55 <+detonate> NTFS sí 13:55 <@jrandom> jdot: los límites de ancho de banda son token buckets (cubo de tokens) estrictos 13:55 <@jrandom> jdot: si estableces la duración de la ráfaga, ese es el periodo sobre el que se promedia 13:56 <@jrandom> (bueno, 2× ráfaga == periodo) 13:56 <@jrandom> ((más o menos)) 13:56 <jdot> hmmm... bueno, tengo 1000 GB y quiero que I2P pueda consumir hasta 800 GB/mes.... 13:56 <+ant> <mihi> detonate: ntfs almacena archivos muy pequeños en la mft, lo que significa casi nada de fragmentación 13:57 <jdot> y no me importa a cuánto haga la ráfaga 13:57 <+detonate> bueno, cuando ejecutas el desfragmentador, se pasa 10 minutos moviendo los 6000 perfiles... así que deben fragmentarse 13:58 <@jrandom> jdot: hmm, bueno, 800 GB probablemente sea más de lo que vaya a querer enviar de todos modos, así que probablemente puedas ir sin límites ;) 13:58 <@jrandom> por otro lado, si pudieras describir una política que te gustaría implementar, quizá podamos manejarlo 13:58 <jdot> jrandom: haré eso por ahora y veré cómo funciona 13:58 <bla> detonate: NTFS, si mal no recuerdo, es un FS con journaling. Así que incluso un archivo monolítico se fragmentará si le escribes porciones pequeñas 13:58 <+detonate> todo se escribe de una vez 13:59 <+detonate> y se lee de una vez 13:59 <bla> detonate: Ok. Ya veo. 13:59 <jdot> jrandom: bueno, esperemos hasta ver si siquiera será un problema. 13:59 <bla> detonate: ¡buen trabajo en ese caso! 13:59 <+detonate> me interesaría saber cuánto uso hay realmente si lo dejas sin límite 14:00 <+detonate> en una buena conexión 14:00 <jdot> ¡yo también! 14:00 <@jrandom> mis routers en colo funcionan sin límite, aunque limitados por CPU 14:00 <+Ragnarok> ¿puedes usar un bitbucket para promediar durante un mes? 14:00 <jdot> jrandom: ¿limitados por CPU? ¿qué tipo de CPU? 14:01 <@jrandom> 4d transfer 3.04GB/2.73GB 14:01 <+detonate> hmm, esperaba menos 14:01 <@jrandom> jdot: limitados por CPU porque ejecuto 3 routers en él, más otras cuantas JVMs, a veces haciendo perfilado 14:01 <+detonate> deben ser esos de bt 14:01 <+detonate> cuando lo del agrupamiento esté en línea, sería interesante ver cómo cambia eso 14:02 <@jrandom> detonate: parte de esa transferencia también soy yo moviendo archivos de 50 MB entre sí ;) 14:02 <+detonate> je 14:02 <jdot> ahh. ok. bueno, veremos qué tal va este sistema. es un AMD XP 2400 con 512 MB y una conexión de 10 Mbit 14:02 <@jrandom> Ragnarok: los token buckets realmente no funcionan así 14:02 <@jrandom> jdot: word, sí, esto es un p4 1.6 iirc 14:03 <@jrandom> Ragnarok: en un token bucket, cada (p. ej.) segundo agregas algunas fichas según la tasa. si el bucket está lleno (tamaño = periodo de ráfaga), las fichas se descartan 14:04 <@jrandom> cuando quieras transferir datos, necesitas conseguir una cantidad suficiente de fichas 14:04 <@jrandom> (1 token = 1 byte) 14:04 <+Ragnarok> sé cómo funcionan... ¿qué pasa si simplemente haces el bucket muy grande? 14:05 <+detonate> entonces nunca dejas de enviar datos 14:05 <+detonate> si su tamaño es infinito 14:05 <+detonate> err, y está lleno de tokens 14:05 <@jrandom> si es realmente grande, puede salir y hacer ráfagas a tasas ilimitadas tras poco uso 14:06 <@jrandom> aunque quizá eso sea deseable en algunos casos 14:07 <@jrandom> la cosa es que no puedes simplemente establecer el token bucket en 800 GB, ya que eso no limitaría la cantidad total transferida 14:08 <+detonate> necesitas un campo ahí donde puedas establecer el número de tokens por segundo; luego puedes simplemente dividir el uso de ancho de banda por mes por el número de segundos 14:08 <+detonate> :) 14:10 <@jrandom> eso es lo mismo que simplemente establecer la tasa promediada durante el mes, lo cual estaría desequilibrado. pero, en fin, hay muchos escenarios posibles: si alguien tiene alguno que cubra sus necesidades y que no se pueda satisfacer con lo disponible, por favor, pónganse en contacto 14:10 <+Ragnarok> pero si estableces la tasa al promedio que quieres... creo que 308 kB/s aquí, y luego pones el bitbucket en algo muy grande... ¿por qué no funciona eso? 14:11 <+Ragnarok> s/larger/large/ 14:12 <+detonate> bueno, podrías configurarlo para que nunca envíe más de 800 GB/44000 en un periodo de ráfaga de 60 segundos 14:12 <+detonate> 44000 siendo aproximadamente el número de minutos en un mes 14:13 <@jrandom> el tamaño del bucket/duración de la ráfaga describe cuánto enviaremos sin restricción, y la mayoría de la gente sí quiere restricciones, para que el router no devore 10 Mbps durante 5 minutos mientras vacía el bucket (o lo que sea) 14:14 <@jrandom> también es posible una limitación adicional de los tokens que salen del bucket (y si ese limitador debería tener su propio token bucket, y ese bucket su propio limitador, etc.) 14:16 <+Ragnarok> pensaba que al bucket solo se le añadían tokens cuando había ancho de banda sin usar 14:16 <@jrandom> los tokens se agregan al bucket a una tasa constante (p. ej., 64k tokens por segundo) 14:17 <@jrandom> cualquier cosa que quiera ancho de banda siempre le pide al bucket 14:18 <+Ragnarok> ah... ok 14:19 <@jrandom> ok, genial, ¿alguien más tiene algo que quiera plantear para la reunión? 14:21 <@jrandom> ok, si no 14:21 * jrandom se prepara 14:21 * jrandom *baf* cierra la reunión