[uylug-varios] Sitios de Speed Test p/fibra??

[Carlos Martinez Cagnazzo]

Hola!

On 3/8/12 12:19 PM, Eduardo Trápani wrote:
> Mirá ... ¿qué hace diferente el FTP del HTTP en relación al throughput? 
No tanto el protocolo mismo sino los clientes. El HTTP en gral asume que 
hay un humano (AKA eyeballs :-) ) que mantener contento (recuerdan 
cuando hablamos de IPv6 y del draft 'happy eyeballs'). Por ello los 
clientes pueden buscar optimizaciones en las opciones de TCP que 
penalicen el throughput en favor del delay, algo similar a cuando en 
Samba seteamos TCP_NODELAY y cosas de esas.
>> La otra herramienta que es buena para llenar caños es el BitTorrent :-)
>> Tomen un torrent con muchos seeders (la última ISO de Ubuntu es en
>> general una buena apuesta en este sentido) y ponganle todos los anchos
>> de banda 'unlimited' y control de ancho de banda en 'manual' (esto
>> ultimo para el uTorrent, no se como será en otros clientes).
> Y un límite alto de peers (si es bittorrent en Preferencias->Red->Número
> máximo de pares por torrent y de pares en general).  Ahí llenás subida y
> bajada bien rápido.  Lo fundamental es buscar algo que sea muy popular.
>   O sea, para la que se llene la subida buscate algo que tenga muchos
> leechers y no tantos seeders.  Para llenar la bajada es como dice Carlos.
Efectivamente me olvidé de ese aspecto, hay que tocarlo también. También 
de acuerdo con los leechers :)

BTW hace un tiempo baje unas ISOs de Ubuntu acá en la oficina en la que 
me aparecieron varios peers IPv6, y como en ese momento teniamos V4 por 
un proveedor y V6 por otro, el uTorrent me llenó *los dos enlaces*, uno 
con tráfico v4 y el otro con v6. Me dí cuenta cuando estaba bajando el 
ISO a 1.5 Mbps cuando normalmente no pasaba de 800 - 900 kbps.
>
>> La ventaja de este ultimo mecanismo es que va a tratar de llenar el caño
>> en *ambas* direcciones, y de esa manera se va a ver mejor como la
>> asimetría del enlace afecta (o no) al throughtput.
> Como es cierto puede afectar, capaz que es mejor medirlos de a uno, si
> te interesa el total del caño de manera "abstracta".  Porque si se te
> llena la subida la bajada va a "sufrir" (básicamente te quedás sin ancho
> de banda para que los ACK se envíen inmediatamente).  Entonces podés
> limitar la subida mientras medís la bajada y a su vez, limitar la bajada
> cuando medís la subida.  Así te asegurás de que una no afecte demasiado
> a la otra.
Exacto. Cuando uno trata de llenar en ambas direcciones el throughput 
llega a un punto de equilibrio diferente del que llega cuando uno solo 
baja o uno solo sube datos.
>
> Totalmente de acuerdo con Carlos en que si liberás los dos, en relación
> a la medida "abstracta", vas a tener una diferencia.  Lo que creo es que
> esa diferencia se va a deber más a tu stack y las "ventanas" de
> transmisión de los equipos intermedios, incluyendo latencia y espacio de
> buffer, que al enlace en sí.
Bufferbloat! http://en.wikipedia.org/wiki/Bufferbloat

s2

Carlos
>
> Eduardo.
> _______________________________________________
> Uylug-varios mailing list
> Uylug-varios at listas.uylug.org.uy
> http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy