<div style="white-space:pre-wrap">Tener en cuenta que por como esta diseñado TCP, cuanto más RTT tengas entre los dispositivos que intercambian datos (más distancia en términos prácticos), menor va a ser la taza de transferencia efectiva... aunque todo el canal sea tuyo y no haya ningún tipo de pérdida de paquetes ni de retransmisiones.<br><br>Por ello, para algunas aplicaciones, existen los "aceleradores de descarga" que entre otras cosas lo que hacen es multiplexar conexiones TCP para "mitigar" el hecho de diseño de TCP.<br><br>Saludos,<br>Nico<br><br></div><br><div class="gmail_quote"><div dir="ltr">El El mié, 9 de nov. de 2016 a las 10:30, Eduardo Trápani <<a href="mailto:etrapani@gmail.com">etrapani@gmail.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Entao, ¿que cosa se mide en sitios como <a href="http://adsltest.com.uy" rel="noreferrer" class="gmail_msg" target="_blank">adsltest.com.uy</a>?<br class="gmail_msg">
<br class="gmail_msg">
Yo entiendo que mide el tiempo que lleva bajar y subir cosas y de ahí<br class="gmail_msg">
calcula la tasa de transferencia, de bits por segundo. Que no es el<br class="gmail_msg">
ancho de banda. Cito a Carlos:<br class="gmail_msg">
<br class="gmail_msg">
> “Ancho de banda” tiene una definición muy clara, no hay que re-definir nada. Ancho de banda es la cantidad de espacio espectral que podes usar en un canal, medido en Hz. Si a esto le agregás la variable de la técnica de codificación, llegás a un valor de ‘bits por hertz’ que podés transmitir. Si a eso le aplicás la ley de Shannon e introducís la relacion S/N, tenes la ‘capacidad de canal’, medida en bits/segundo.<br class="gmail_msg">
><br class="gmail_msg">
> Todo lo demas a lo cual le aplicamos el término libremente en realidad son tasas de bits/segundo que obedecen a diferentes limitaciones, algunas físicas otras impuestas por el equipamiento o el proveedor.<br class="gmail_msg">
<br class="gmail_msg">
En general, si tu proveedor te ofrece un servicio de esos, es porque la<br class="gmail_msg">
bajada y subida se hace a un lugar que está MUY "cerca", en términos de<br class="gmail_msg">
red. Idealmente, si pudieras hacerlo con el próximo "salto", entonces<br class="gmail_msg">
tendrías una muy buena aproximación. A medida que te "alejás" la<br class="gmail_msg">
aproximación empeora, porque hay más gente en el medio, con sus<br class="gmail_msg">
latencias (el paquete sube y baja por un stack, por ejemplo) o sus<br class="gmail_msg">
limitaciones.<br class="gmail_msg">
<br class="gmail_msg">
Eso, suponiendo que vos le estás dando todo el canal a la prueba. Si hay<br class="gmail_msg">
más clientes activos en la red, activos, la medida no va a dar bien.<br class="gmail_msg">
<br class="gmail_msg">
Es algo gráfico, para usuarios. Vos podés usar iperf (lo sugería Carlos<br class="gmail_msg">
como alternativa ideal). Primero un traceroute para identificar un salto<br class="gmail_msg">
cercano y después iperf a eso.<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
Uylug-varios mailing list<br class="gmail_msg">
<a href="mailto:Uylug-varios@listas.uylug.org.uy" class="gmail_msg" target="_blank">Uylug-varios@listas.uylug.org.uy</a><br class="gmail_msg">
<a href="http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy" rel="noreferrer" class="gmail_msg" target="_blank">http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy</a><br class="gmail_msg">
</blockquote></div>