Tests de velocidad para banda ancha (y V): El crecimiento gradual de la ventana (o cómo el fichero de descarga se nos queda pequeño)
Publicado el Agosto 21, 2008 por Francisco Javier Ramón
Archivado bajo Banda ancha, Futuro de Internet, Sociedad de la Información, Tecnologías
(Votos: 13. Media: 4.54/5) 
Loading ...Además de las limitaciones asociadas al tamaño máximo que puede alcanzar la ventana, nos encontramos con la problemática adicional de que TCP, prudentemente, no empieza la transferencia con el tamaño definitivo de ventana. Por el contrario, como ya hacía la empresa de paquetería de nuestro ejemplo, TCP comienza con una ventana de un solo paquete y la va aumentando poco a poco hasta detectar el punto “de saturación”.
En consecuencia, la velocidad de transferencia no será la máxima posible desde el primer momento, sino que irá creciendo paulatinamente hasta estabilizarse alrededor del ancho de banda disponible. Por tanto, habrá un tramo al principio de cualquier conexión (al que se denomina, “fase de slow start”) en el que el caudal aún no ha alcanzado la capacidad realmente disponible. Este período será tanto mayor cuanto más alta sea la velocidad final que deba alcanzarse. Así, este comportamiento “prudente”, que es muy adecuado para evitar problemas de congestión en la red, supone una dificultad significativa para estimar la velocidad de un acceso de alta capacidad.
Para entender mejor la importancia del problema, supongamos que un piloto de Fórmula 1 quisiera medir la velocidad que su bólido es capaz de obtener en un determinado circuito y que, para ello, pidiera que le cronometrasen el tiempo que tarda en dar 4 vueltas. Si el piloto comenzara la prueba ya lanzado a su máxima velocidad, podríamos estimar esta velocidad dividiendo la distancia total recorrida (4 vueltas al circuito) por el tiempo total invertido. Sin embargo, si para evitar problemas con los neumáticos, nuestro piloto decidiera hacer la primera vuelta en 1ª, la siguiente en 2ª, y así sucesivamente, está claro que la estimación de velocidad que hemos hecho sería totalmente errónea, pues, a la 4ª vuelta aún no habría llegado, ni mucho menos, a utilizar la marcha más rápida del vehículo.
Llegados a este punto, nuestro piloto tendría dos soluciones posibles:
- Prolongar la prueba lo suficiente para que la inclusión del período de “calentamiento” acabe por suponer un error despreciable en la medida.
- Descartar completamente la fase de “calentamiento” y comenzar a medir cuando estemos seguros de que el coche está corriendo a su máxima velocidad.
De la misma manera, en un test de velocidad deberemos garantizar que el período de slow start no afecta significativamente a la medida, asegurándonos de que la descarga es suficientemente grande para que se llegue a la máxima ventana y que esta primera fase de “aceleración” no sesga significativamente la estimación. Desgraciadamente, en los tests que siguen las metodologías habituales, se descarta directamente la segunda opción (excluir el slow start) y se confía exclusivamente en que la duración de la prueba sea suficiente.
Para hacernos una idea de los órdenes de magnitud, a continuación se muestran los tamaños de descarga de algunos de los tests de velocidad más populares en España:
Como puede apreciarse, los Tests A, B y C tienen el mismo tamaño de descarga, 7,5 Mbytes (el tamaño típico de un test de Ookla), mientras que el Test D emplea una descarga aún más pequeña.
¿Son suficientes estos tamaños de descarga? Para comprobarlo, representaremos la evolución real del caudal de una conexión TCP en un acceso de 30 Mbps y el resultado que se obtiene con un test convencional de velocidad (que sume los bytes totales transferidos y los divida por la duración de la prueba hasta ese momento). Así mismo, se representará en la misma gráfica el resultado que se obtendría con un test “alternativo” en el que modificásemos la metodología que conocemos, para excluir explícitamente la fase de slow start.
Como puede apreciarse, en un test de velocidad convencional se necesitan varias decenas de Mbytes para estimar con cierta precisión el ancho de banda del acceso de 30 Mbps. Así, los tests de velocidad A, B y C (7,5 Mbytes) estimarían, en el mejor de los casos, unos 25 Mbps (83% del valor real), mientras que el Test D, apenas llegaría a los 20 Mbps (menos del 70%). Así mismo, cabe destacar que, empleando una metodología alternativa que excluyera directamente la fase de slow start, sería posible obtener una estimación bastante precisa con descargas de algo menos de 1 MByte.
CONCLUSIONES
Los tests de velocidad están llamados a jugar un importante papel en la evaluación de la calidad del servicio de banda ancha. Al tradicional rol de “auditores de la banda ancha”, cuyo impacto desborda el ámbito del propio sector TIC y comienza a calar en la opinión pública en general, se une el posible papel que puedan desarrollar en un futuro próximo dentro del ámbito regulatorio. Para desempeñar correctamente estos dos cometidos y que su labor finalmente se traduzca en la mejora de los servicios de banda ancha y en el aumento de la transparencia del mercado, es necesario que éstos realicen su cometido con la mayor fiabilidad y precisión.
Sin embargo, después del análisis pormenorizado de estos tests de velocidad y sus metodologías de medida, nos encontramos con que una gran parte de los medidores actualmente disponibles, aunque siguen siendo adecuados para las modalidades tradicionales de acceso, no consiguen hacer estimaciones fiables de velocidad en los nuevos accesos de alta capacidad. Así, factores como la configuración de ventana TCP en el equipo de cliente o en el propio servidor, que conducen a serias limitaciones en la velocidad máxima que puede medirse, siguen sin tenerse en cuenta a la hora de contrastar los resultados de una estimación de velocidad.
De la misma manera, problemas latentes en la propia metodología de medida, que permanecían ocultos a bajas velocidades, parecen tener ahora un efecto más evidente. Tal es el caso de la inclusión sistemática de la fase de slow start de TCP en el cómputo global de la medida, lo que, a altas velocidades, comienza a producir desviaciones más que significativas.
A la mejora continuada de estos sistemas de medición habrán de dedicar una buena dosis de atención todos los agentes implicados, de manera que dispongamos los usuarios de medios adecuados para controlar la calidad del servicio que se nos ofrece, y que esto pueda traducirse finalmente en una mejora continuada en nuestra experiencia con la banda ancha.
ENTRADAS DE ESTA SERIE:
- La importancia de una estimación precisa.
- ¿Cómo funciona un test de velocidad?
- TCP, la empresa de paquetería.
- Las limitaciones de la ventana (o cómo el sistema operativo sabotea nuestra medida).
- El crecimiento gradual de la ventana (o cómo el fichero de descarga se nos queda pequeño).
Tags: ADSL, ancho de banda, Banda ancha, fibra, HSDPA, Internet, tests de velocidad, xDSL
Comentarios
3 Comentarios to “Tests de velocidad para banda ancha (y V): El crecimiento gradual de la ventana (o cómo el fichero de descarga se nos queda pequeño)”
Deja una respuesta
Suscripciones
Creative Commons
Los contenidos de este blog están bajo una licencia de Creative Commons. Pueden utilizarse, pero sin fines comerciales y citando la fuente.
Suscríbete a La Cofa
El proveedor de acceso a Internet controla por completo el tramo entre el enrutador en casa del usuario y el siguiente enrutador en la central telefónica y es allí donde debe ofrecer la velocidad ofertada. Si el test de velocidad se realiza contra un servidor en cualquier punto de Internet el proveedor de acceso no es responsable del resultado excepto si se puede mostrar que es el cuello de botella. En la página web de gestión de muchos routers ADSL se puede ver la velocidad real de la línea ADSL en el nivel físico, tanto de subida como de bajada y es menor cuanto más lejos se está de la central. Otro factor importante es la calidad del canal en cuanto a errores. Ruido en la línea supone paquetes perdidos y el TCP lo interpreta como congestión y reduce la velocidad de transferencia. La tasa de error de bit de la línea ADSL también se puede ver en la página web de gestión del enrutador. Si se desactiva el entrelazado (Jazztel lo permite), se obtiene una menor latencia que mejora las prestaciones para jugar en línea, pero que puede dar problemas con los vídeos o transferencias TCP largas, al aumentar la tasa de error del canal.
[...] para medir la calidad del acceso a Internet. El índice con el resto de los artículos en: http://www.lacofa.es/index.php/tecnologias/tests-de-velocidad-para-banda-ancha sin comentarios en: tecnología, internet karma: 17 etiquetas: adsl, banda ancha, velocidad, [...]
Muy interesante el articulo. mil gracias..