Reunión de desarrolladores de I2P - 7 de marzo de 2006

15:08 <jrandom> 0) hola 15:08 <jrandom> 1) Estado de la red 15:08 <jrandom> 2) ??? 15:08 <jrandom> 0) hola 15:08 * jrandom saluda con la mano 15:08 <jrandom> notas semanales de estado publicadas en http://dev.i2p.net/pipermail/i2p/2006-March/001267.html 15:09 * jrandom les da a todos horas para leer ese enorme tocho de notas 15:10 * Complication finge no haberse dado cuenta aún ;) 15:11 <+Complication> Hola :) 15:11 <+susi23> hola :) 15:12 <jrandom> bueno, más vale meternos con 1) estado de la red 15:12 <jrandom> El correo da mi visión general de lo que está pasando. ¿Cómo se alinea eso con lo que están viendo ustedes? 15:13 <+Complication> Las correcciones a la limitación parecen haber aumentado la fiabilidad, pero han reducido bastante el ancho de banda 15:13 <+Complication> Un segundo, buscando el gráfico 15:14 <+Complication> http://complication.i2p/files/bw-week.webp 15:14 <+Complication> Los tramos altos son con versiones no más recientes; los bajos, con la última 15:15 <+Complication> Las mismas configuraciones del limitador, posiblemente más laxo con las versiones más estrictas (las últimas) 15:16 <+Complication> Pero no es mucho problema, ya que sí transfiere 15:16 <jrandom> genial, un menor uso de ancho de banda es apropiado a medida que te acercas a tu límite real de ancho de banda 15:17 <+Complication> La mayoría del tiempo, parece retroceder antes del límite de «ancho de banda sostenido» 15:17 <+Complication> Nunca toca el límite de ráfaga 15:18 <+Complication> (lo cual, en sí, es sensato; lo que me preocupa es el retroceso antes del límite sostenido) 15:19 <bar> estoy viendo más o menos lo mismo que Complication. mi consumo total de ancho de banda es solo el 50% de mi configuración máxima. solía ser ~80% antes de la 0.6.1.11 15:19 <jrandom> ¿es 200kbps tu tasa del limitador, con 300kbps de ráfaga? 15:20 <jrandom> (solo me pregunto cuánto tiempo solía pasar en la ráfaga) 15:20 <jrandom> aun así, reducir el uso de ancho de banda es uno de los objetivos de los cambios recientes 15:21 <+Complication> ~225 sostenido, ~325 ráfaga 15:21 <+Complication> Eh, podría haber... 15:22 <+Complication> ¿Lo he *interpretado* mal? 15:23 <+Complication> Olvídalo, soy un tonto... hice mal las cuentas, no es ni de lejos tan malo :O 15:23 <jrandom> datos insuficientes :) podría ser indicativo de un problema, pero lo que has descrito hasta ahora sugiere que las cosas se comportan como se desea 15:23 <+Complication> Es un poco conservador, pero no tan malo como pensaba 15:24 <+Complication> Según la Router Console (que mide en la misma unidad que el limitador), el promedio total de salida es 2/3 del límite sostenido y 1/2 del límite de ráfaga 15:25 <+Complication> Pero el promedio total de entrada, tengo que decir, está solo un poco por encima de 1/3 del límite sostenido y 1/4 del límite de ráfaga 15:26 <+Complication> por ejemplo, asumiendo un límite sostenido de 30 y un límite de ráfaga de 40, la salida sería 20 y la entrada apenas por encima de 10 (principalmente por falta de carga) 15:26 <jrandom> genial 15:26 <+Complication> Pero el gráfico lo interpreté mal, por problemas de Kb/KB :O 15:27 * Complication borra el gráfico del historial 15:28 <jrandom> buen ojo, de todos modos; definitivamente avísame cuando las cosas suenen raras 15:28 <jrandom> ok, ¿algo más sobre 1) Estado de la red? 15:28 <jrandom> si no, pasemos a 2) ??? 15:28 <jrandom> ¿alguien tiene algo más que discutir? 15:30 <+Complication> Bueno, ha habido algunas pruebas de jbigi y, al parecer, alguien obtuvo resultados que sugerían que la versión de 64 bits para Linux era algo lenta 15:31 <+Complication> Les salía más lenta que Java puro; no estoy seguro si fue un fallo de medición o no :O 15:32 <+Complication> No pude reproducirlo 15:32 <jrandom> sí, no estaba seguro exactamente de qué .so estaban usando para la plataforma 15:32 <+Complication> Por aquí, era aproximadamente el doble de rápido que Java puro 15:32 <+dust> mis experimentos con html como formato de mensaje adicional en syndie están empezando a funcionar. mi 'sucker' local ahora puede recuperar páginas web (con imágenes) y almacenarlas como publicaciones de syndie 15:33 <jrandom> ah, genial, dust 15:33 <+dust> pero sin css 15:33 <+Complication> Pero la gente en 32 bits dijo que era *mucho* más rápido que Java puro (como 10x o similar) 15:35 <bar> hmm.. Complication, ¿podría ser que el .so amd64 actual sea solo para sistemas de 32 bits y lo probó en un SO de 64 bits? 15:36 <+Complication> bar: podría ser, ya que yo también lo probé en un SO de 64 bits :O 15:36 <jrandom> si mal no recuerdo, el amd64 se compiló para funcionar en Debian pure64 15:37 <+Complication> En cualquier caso, algunas personas sugirieron que importar un gmp más reciente podría ayudar 15:37 <bar> solo un tiro al aire, no soy un hacha en estas cosas 15:37 <jrandom> eh, usamos 4.1.4 15:37 <+Complication> Especialmente después de que hagan su inminente salto de versión 15:38 <+Complication> Como no soy especialista en gmp, no puedo decir mucho al respecto 15:38 <jrandom> (y es poco probable que las próximas optimizaciones en gmp supongan una mejora sustancial) 15:38 <+Complication> Aparte de «quizás, de hecho» 15:38 <jrandom> las mejoras vienen de compilaciones por arquitectura 15:40 <+Complication> En mi prueba, provocada por su prueba, la biblioteca para Athlon de 64 bits en un Sempron de 64 bits, en un Mandriva de 64 bits, sin embargo... parece solo marginalmente más rápida que Java puro 15:40 <+Complication> (ah, y una VM de 64 bits) 15:41 <+Complication> (marginalmente siendo el doble) 15:41 <jrandom> hmm 'k 15:42 <+Complication> Intentaré probar en más combinaciones de plataformas y avisaré si encuentro algo que valga la pena transmitir 15:43 <jrandom> genial, gracias 15:43 <jrandom> ok, ¿alguien tiene algo más para la reunión? 15:46 <jrandom> si no... 15:46 * jrandom termina 15:47 * jrandom *baf* cierra la reunión