Archivo para la categoría 'Banda ancha'
Research@Intel Day 2009
Publicado el Junio 24, 2009 por rsad
Archivado bajo Banda ancha, Futuro de Internet, General, Innovación, Movilidad, Tecnologías
(Votos: 2. Media: 4.5/5) 
Loading ...El pasado 18 de Junio se celebró en Silicon Valley el Research@Intel Day 2009 una exposición en la que Intel mostró más de 45 proyectos de investigación en los que estan trabajando. Entre los proyectos más destacados se encontraban los relacionados con la eco-tecnología, los gráficos y el futuro de la movilidad.
Algunos de los video estan disponibles, pero la mejor opción fue seguirlo mediante Streaming en directo.
Proyectos destacados :
Nanotubos de carbono para Chips en el futuro?
Los investigadores Irlandeses de Intel como parte del CARBonCHIP consortium, estan investigando cómo aprovechar la tecnología de los nanotubos de carbono para crear los chips del futuro. Estos materiales tienen unas características muy especiales, como puede ser una muy baja resistencia eléctrica así como una gran capacidad de conducción. El mayor problema de estos materiales es la gran complejidad para su creación lo cual hace que , por ahora, no sea viable su comercialización.
Lenguaje de programación determinístico paralelo para un mundo Multi-Core:
Es una idea común a todos los desarrolladores de procesadores el que en el futuro estos no escalarán incrementando la frecuencia de procesado si no aumentando el número de núcleos de los procesadores. Para obtener un mejor rendimiento de estos futuros procesadores Intel está desarrollando nuevos lenguajes que utilicen todo el potencial que esta nueva arquitectura posee. Este nuevo lenguaje en paralelo tiene dos características principales , la ejecución determinista y el uso de librerias de alto rendimiento.
Plataforma mundial virtual Open-Source :
Intel está trabajando para ofrecer una plataforma con la que poder desarrollar un mundo virtual Open-Source como es OpenSim. Para ello está creando herramientas con las que cualquiera podría crear un entorno virtual de alta calidad. Intel está ayudando a abrir estas nuevas tecnologías a usuarios individuales así como a universidades y compañias que estan interesadas en crear el mundo en 3-D del internet del mañana.
Intel: Clone Cloud
Esta propuesta consiste ,esencialmente , en crear una “nube” para el procesado de las aplicaciones más pesadas que utilizan los teléfonos móviles. Se basa en clonar los datos que contiene el terminal móvil en un repositorio en la nube, de este modo cuando se necesitan hacer operaciones complicadas con estos datos no se realizan en el terminal, si no que este manda la orden a la nube. En la nube se ejecutan los procesos pesados (como por ejemplo el tratamiento de imágenes) y se almacena el resultado, el cual luego se presenta en el terminal móvil.
Obteniendo energia del aire :
Investigadores del laboratorio de Intel en Seattle han desarrollado WARP (Wireless Ambient Radio Power). Esta tecnología recolecta energia de las transmisiones de televisión que generalmente se pierden en la atmósfera. A una distancia de 4.1 kilómetros los investigadores consiguieron 60uW, una cantidad muy pequeña, pero suficiente para alimentar equipos electrónicos de muy bajo consumo como pueden ser sensores.
Tags: cloud computing, comunicaciones, energia, evento, Internet, mundos virtuales, pantallas, servicios moviles
Cloud personal
Publicado el Abril 7, 2009 por Javier Carbonell
Archivado bajo Banda ancha, Futuro de Internet, Movilidad, Sociedad de la Información, Tendencias
(Votos: 3. Media: 3/5) Loading ...blank_pageEs el término de moda de los sistemas de información. Servicios en la “cloud”, almacenamiento en la “cloud”, plataformas en la “cloud”… Hasta hace bien poco era un término desconocido y ahora parece que no se puede vivir sin él. La magnitud de este concepto se puede ilustrar con las previsiones de Gartner de que en el año 2013 la mitad del gasto informático de empresas (150 billones $) estará relacionado con él.
Sin duda alguna las ventajas de esta forma de operar son claras, una reducción de costes importante y ubicuidad. Por contra la gran desventaja viene del lado de la privacidad de nuestros datos.
El usuario tiene que suponer la honradez de las empresas que ofrecen el servicio, y en estos tiempos suponer honradez es quizás suponer demasiado. El otro gran problema proviene del peligro de confiar nuestros datos a un proveedor que no sabemos si puede existir dentro de unos años. En este caso no solo me refiero a start-ups, algunas empresas grandes como HP y Yahoo no han dudado en cerrar algunos de sus servicios “cloud”. Se supone que no debería ser difícil recuperar la información pero otra vez debemos andar con suposiciones.
Estos problemas se pueden mitigar en el caso de que el cliente sea una empresa llegando a compromisos de acuerdos de nivel de servicio con una empresa proveedora que goce de buena reputación. En el caso de que el cliente sea un usuario individual la verdad es que la empresa no se suelen responsabilizar de nada. Si leemos los términos de contrato de cualquiera de estas empresas, por ejemplo Mozy , nos damos cuenta de que no tienen ningún desperdicio y encontramos muchas de perlas como esta:
Para estos casos en los que un usuario quiere poder acceder a sus datos desde cualquier lugar y en cualquier momento y no se fía de la “cloud”, la solución puede ser construirse su “cloud” personal. La primera opción sería disponer de un servidor funcionando en su hogar lo cual es bastante molesto, otra opción más práctica consiste en disponer de un disco duro en el entorno del hogar al cual se pueda acceder a través de Internet con los mecanismos de seguridad necesarios. Ya existen varias soluciones como el producto AirPort Extreme de Apple que permite compartir cualquier información dentro del hogar digital y también el acceso seguro desde el exterior contratando MobileMe. Este concepto de cloud personal puede sufrir un gran avance con la llegada al mercado de Pogoplug, un pequeño dispositivo que te permite conectar un disco duro USB y acceder a él desde el exterior soportando diversos sistemas operativos y hasta el iPhone.
Sin duda puede ser una solución para quienes están deseando que sus datos se encuentren en la Red pero no ceder el control de la información a nadie, al menos hasta que el mundo “cloud” vaya asentándose y ganando credibilidad.
Tags: airport extreme, cloud, personal cloud, pogoplug
La televisión interactiva no tanto en cuanto a los contenidos sino como experiencia social
Publicado el Octubre 3, 2008 por Luis Fernando Solórzano
Archivado bajo Banda ancha, Futuro de Internet, Ideas de negocio
(No valorado aún) Loading ...Según el informe titulado “Innovation at the Edge: Social TV and Beyond” del grupo de trabajo “Value Chain Dynamics” del MIT Communications Future Program, las aplicaciones sociales de televisión son una categoría emergente de servicios interactivos de vídeo.
Existen oportunidades de negocio en la televisión interactiva, pero no tanto en cuanto a que los contenidos sean interactivos sino como experiencia social. Las aplicaciones sociales que giran en torno a los servicios de vídeo incitan a la interactividad en tiempo real entre grupos de espectadores (“shared viewing”), de forma similar a los comentarios o respuestas en vídeo que aparecen en YouTube y otros servicios similares. De hecho, existe una experiencia parecida en la televisión actual en ciertos programas que te animan a enviar comentarios por SMS de forma que luego aparecen (en directo) como subtítulos en la parte inferior de la pantalla.
En servicios como YouTube existe además el concepto de “amigos” y “favoritos”, de forma que puedes saber lo que están viendo tus amigos y cuáles son sus vídeos favoritos. La recomendación de tus amigos es siempre un criterio importante a la hora de elegir una serie o una película. Lo próximo en YouTube es que vamos a poder marcar las escenas más interesantes o graciosas de un vídeo como en los programas de zapping. ¿No podríamos tener una experiencia social parecida con la televisión?
La posibilidad de grabar programas de televisión y compartirlos (P2P) con gente de cualquier país del mundo amplía las posibilidades de entretenimiento hasta más allá de lo que tu disponibilidad de tiempo te permite disfrutar. Eso también favorece a las aplicaciones sociales de televisión, porque así todo el mundo puede tener acceso a los mismos contenidos aunque no hayan sido emitidos por las emisoras locales. Es importante evitar la fragmentación porque si no hay una masa crítica importante es díficil que una red social tenga éxito.
En cuanto a los retos técnicos que las aplicaciones sociales de televisión deben superar, uno de ellos es la diversidad de terminales. No se trata solo de la pantalla de televisión que tenemos en el salón, hay que considerar otros dispositivos como el ordenador o el móvil o el reproductor multimedia portátil, etc. Se están haciendo esfuerzos por desarrollar un midleware que permita integrar estas “funciones sociales” en los contenidos. Por ejemplo, el Open IPTV Forum se está definiendo un API abierto para que los desarrolladores de aplicaciones sociales puedan acceder al “set-top box”.
En un escenario como este, los operadores pueden tener un papel muy importante ya que tienen las capacidades de red necesarias para garantizar una QoS frente a la política “best-effort” de las redes públicas como Internet.
Tags: IPTV, redes sociales, television, tv
NetSpa genera una representación visual de patrones de ataque a redes de ordenadores
Publicado el Septiembre 16, 2008 por Luis Fernando Solórzano
Archivado bajo Banda ancha, Futuro de Internet
(No valorado aún) Loading ...El grupo Information Systems Technology del MIT Lincoln Laboratory organiza en esta semana dos eventos relacionados con las tecnologías de seguridad y visualización: RAID2008 (11th International Symposium on Recent Advances in Intrusion Detection) y VizSec2008 (5th International Workshop on Visualization for Cyber Security). Investigadores de este mismo centro, bajo la dirección de Richard Lippman, han desarrollado NetSPA (Network Security Planning Architecture).
NetSpa encuentra las vulnerabilidades más críticas combinando la información que proviene de los escaner y reglas de filtrado definidas, así como la estructura física de la red. El resultado del análisis es una representación gráfica de los patrones de ataque más probables y una lista de acciones recomendadas que los administradores de sistemas deberían realizar para prevenir los riesgos de ataque más críticos.
Aplicar esta tecnología a sistemas de red en tiempo real es un gran reto. De hecho, la versión original de NetSpa tenía una limitación de 17 ordenadores por red. Los investigadores están ahora optimizando su capacidad de proceso modificando el algoritmo de simulación.
Lincoln Laboratory tiene patentado (US7194769B2) el tipo de ataque “predictive attack graph” y ha solicitado la patente para otro tipo de ataque denominado “multiple prerequisite attack graph”. Además, un grupo de estudiantes del MIT ha elaborado un plan de negocio para explotar comercialmente esta tecnología bajo la marca de la recién creada empresa CyberAnalytix. Dicho plan de negocio ganó un premio de 10.000 dólares en la competición MIT $100K Entrepreneurship.
Tags: lincoln lab, MIT, netspa, patentes, seguridad, simulación, visualización
¿Por qué se preocupan los norteamericamos por su banda ancha? (y II)
Publicado el Septiembre 13, 2008 por M Ruth Gamero
Archivado bajo Banda ancha, Sociedad de la Información, Tecnologías, Tendencias
(No valorado aún) Loading ...Ya avanzábamos en otro post anterior la preocupación de los expertos por el desarrollo de la banda ancha en EE.UU. Y ante esta situación ¿qué recomiendan?
En resumen, apostar por políticas públicas que consigan que haya una gran mayoría de hogares que usen redes de banda ancha de alta velocidad para todo tipo de actividades online, incluyendo educación, salud, trabajo, comercio así como para interactuar con la administración. Y para ello, como se comentaba anteriormente, se trata de llevar a cabo actuaciones que promuevan tanto oferta como demanda.
Para promover el desarrollo de infraestructuras de BA:
1. Enact more favorable tax policies to encourage investment in broadband networks, such as accelerated depreciation and exempting broadband services from federal, state, and local taxation.
2. Continue to make more spectrum, including “white spaces,” available for next-generation wireless data networks.3. Expand the Department of Agriculture’s Rural Utilities Service Broadband Program and target the program to places that currently do not have non-satellite broadband available.
4. Reform the federal Universal Service Fund program to extend support for rural broadband to all carriers, and consider providing the funding through a reverse auction mechanism.
5. Fund a national program to co-fund state-level broadband support programs, such as Connect Kentucky or North Carolina e-NC Authority.
6. Promote the widespread use of a national, user-generated, Internet-based broadband mapping system that would track location, speed, and price of broadband.
7. State and local governments should take action to make it easier for providers to deploy broadband services, including making it easier to access rights-of-way.
Y para promover el aumento de la demanda de BA:
8. Support initiatives around the nation to encourage broadband usage and digital literacy.
9. Fund a revitalized Technology Opportunities Program, with a particular focus on the development of nationally scalable Web-based projects that address particular social needs, including law enforcement, health care, education, and access for persons with disabilities.
10. Exempt broadband Internet access from federal, state, and local taxes.
11. Support new applications, including putting more public content online, improving e-government, and supporting telework, telemedicine, and online learning programs.
Se trata de mejorar la situación desde las dos aproximaciones, invirtiendo en infraestructura tanto en medios rurales como en urbanos e incentivando a los consumidores a consumir banda ancha de alta velocidad, objetivo que se consigue sólo si hay utilidad detrás del servicio.
Es decir, introduciendo la realidad digital en las vidas de las personas.
Tags: Banda ancha, demanda, oferta, regulación
¿Por qué se preocupan los norteamericamos por su banda ancha? (I)
Publicado el Septiembre 12, 2008 por M Ruth Gamero
Archivado bajo Banda ancha, General, Sociedad de la Información, Tecnologías, Tendencias
(No valorado aún) Loading ...Estados Unidos ha sido y es referente en cuanto al desarrollo de Internet en el mundo. Pero si acudimos a los indicadores relacionados con la banda ancha su posición dista bastante de los puestos de cabeza (se encuentra en el puesto 15) en una caída que empezó en 2001.
Penetración de usuarios de Internet y de banda ancha (mundo, por regiones). ITU 2007
Los nórdicos Dinamarca, Holanda e Islandia, encabezan la lista en cuanto a líneas por cada 100 habitantes según datos de la OCDE y aunque en penetración de usuarios de Internet los estadounidenses se encuentren a la cabeza, tanto la media de la UE-15 como las grandes economías asiáticas adelantan a la media norteamericana de penetración de usuarios en banda ancha.
Líneas de banda ancha (20 países más avanzados de la OCDE). 2007
Recientemente en el marco de ITIF Forum (Information Technology and Innovation Foundation), un think tank cuya misión es formular y promover políticas públicas para avanzar en la innovación tecnológica y en la productividad se presentó un estudio especial titulado “Explaining International Broadband Leadership” en el que sus autores trataban de encontrar lo puntos clave de dicha desviación de EE.UU. y apuntaban las posibles vías de solución.
Según el estudio, en el desarrollo de la banda ancha de un país intervienen muchos factores. Por ejemplo, el hecho de que el 50% de los sur-coreanos vivan en apartamentos en grandes edificios hace que sea significativamente más barato desplegar la banda ancha en estos lugares, que en Estados Unidos donde la mayoría de las familias viven en casas cercanas a la ciudad pero fuera de los núcleos urbanos. Asimismo, el hecho de que EE.UU. tenga las mayores longitudes de bucle hace que sea más caro el despliegue de banda ancha de buena calidad a bajo coste. Por lo que un modelo válido en un país puede no serlo en otro. Lo que sí parece útil es analizar las buenas prácticas que llevan a cabo otras naciones en materia de banda ancha, particularmente en programas individuales e iniciativas para impulsar el despliegue y la demanda.
Así pues para incentivar el desarrollo de la banda ancha se puede, o bien tirar de la oferta o de la demanda, o de las dos.
Se puede tirar de la oferta a través de incentivos: para los operadores desplegar redes de banda ancha es caro y sobretodo en entornos rurales. Muchos países han decidido incrementar el suministro de banda ancha más allá de lo que provee el mercado. Así las principales naciones en penetración de banda ancha usan incentivos para impulsar su despliegue. Por ejemplo, en Suecia el gobierno proporciona subvenciones para impulsar el despliegue, particularmente en las áreas rurales, a lo que destinó un total de más de 800 millones de dólares.
Se puede desarrollar la oferta a través de la competición: muchos defensores de la banda ancha creen que el éxito de ésta en Europa, especialmente en Francia, se debe en gran medida a las regulaciones en desagregación, y reivindican que EE.UU. adopte políticas de desagregación para motivar la competición intramodal. Tienen razón en el sentido de que la competición es importante para el éxito de la banda ancha, pero pasan por alto varias claves. Primero, la competición intermodal entre redes físicas separadas (por ejemplo, entre servicios DSL y servicios por cable módem) también puede propiciar el éxito de la banda ancha. Segundo, la competición intramodal no es la panacea. Ciertos países de la UE con regímenes de desagregación similares a los de Francia, como Italia y España, están por debajo de EE.UU. en cuanto a adopción de esta tecnología. Además, muchos de los países de la UE adoptaron regulaciones de desagregación porque a penas tenían competición intermodal en banda ancha – en parte porque las regulaciones en cable limitaban las inversiones en servicios de cable módem. Aunque las políticas de desagregación proactivas debían haber impulsado la adopción de servicios DSL en muchos países, las políticas de desagregación agresivas, particularmente las de redes de próxima-generación (fibra y cable de alta velocidad), corren el riesgo de limitar las inversiones para ambos, titulares y competidores en estas redes, y puede dar como resultado una velocidad modesta en sus bucles.
Se puede desarrollar la demanda con la subvención de dispositivos, el desarrollo de servicios y educación: dado que solo las dos terceras partes de los americanos tienen PC en el hogar, incluso las más robustas políticas de suministro no producirían un uso universal de la banda ancha. Otros países han tenido más en cuenta la demanda. El gobierno sueco subvencionó las compras de PCs con reducciones de impuestos para compañías que dieran PCs a sus empleados para uso privado, y como resultado, casi el 90% de los suecos tienen acceso a Internet en el hogar mediante un PC. Asimismo el objetivo de la Agency for Digital Opportunity and Promotion Korea de Corea del Sur es promover la alfabetización digital y el acceso a los ordenadores, mediante programas de entrenamiento y un sistema de compras a un precio reducido.
En un próximo artículo se resumirán las propuestas de este foro para incentivar el desarrollo de la banda ancha.
Tags: Banda ancha, demanda, desarrollo, oferta
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
Tests de velocidad para banda ancha (IV): Las limitaciones de la ventana (o cómo el sistema operativo sabotea nuestra medida)
Publicado el Agosto 20, 2008 por Francisco Javier Ramón
Archivado bajo Banda ancha, Futuro de Internet, Sociedad de la Información, Tecnologías
(Votos: 6. Media: 5/5) Loading ...Como vimos en el post anterior, si TCP sólo enviase un paquete cada vez y esperase a la llegada de su ACK para mandar el siguiente, podría llegarse a la paradoja de que el retardo de propagación de ida y vuelta (RTT) se convirtiera artificialmente en el cuello de botella de la transmisión, en lugar de serlo la propia capacidad del enlace (sólo se enviaría un paquete por cada ciclo de RTT). Por ese motivo, TCP mantiene un número determinado de paquetes “en vuelo” sin haber recibido aún su confirmación, de manera que es capaz de aprovechar eficientemente el enlace. A este número de paquetes “en vuelo” es a lo que se denomina ventana.
El tamaño adecuado de esa ventana se calcula dinámicamente a lo largo de la conexión, adaptándose al RTT que haya en cada momento, de manera que en cada ciclo de RTT se manden suficientes paquetes para ocupar el ancho de banda disponible (lo que equivale a “llenar la cinta transportadora” en el ejemplo anterior).
Sin embargo, el margen que tiene el protocolo TCP para adaptar dinámicamente su ventana no es indefinido. Además de las limitaciones que dicte la propia capacidad de la línea, TCP tiene que trabajar de acuerdo a los valores máximos de ventana que estén configurados en los sistemas operativos de cada uno de los extremos, de manera que en ningún caso se le permitirá trabajar con una ventana que supere en tamaño a los valores máximos prefijados en el emisor y el receptor.
De esta forma, una conexión TCP sólo será capaz de aprovechar al máximo el ancho de banda disponible si ambos extremos tienen una configuración de ventana máxima suficientemente holgada para las condiciones de funcionamiento. En particular, los tamaños de ventana TCP tanto del extremo receptor como del emisor deben ser suficientes para trabajar con las condiciones de RTT y ancho de banda máximo disponible entre los dos extremos, teniendo en cuenta que, a mayor RTT, mayor deberá ser la ventana para alcanzar una determinada velocidad de descarga, pues se tiene que:
(tal y como sucedía en nuestro símil de la cinta transportadora)
Para comprobar el impacto que esta limitación puede tener en un test de velocidad, consideremos el caso de un usuario con Windows XP que quiere comprobar la velocidad de su nuevo acceso xDSL de 30 Mbps usando un medidor de velocidad. Si tenemos en cuenta que la ventana máxima por defecto en Windows XP es de 64 KBytes y tomamos como referencia los RTT hacia algunos de los tests de velocidad más populares en España (por ejemplo, con un ping…), podemos elaborar una tabla como la siguiente, haciendo una simple división:
Así, tendríamos que si nuestro usuario utilizase el Test A para medir su velocidad, acabaría descubriendo alarmado que éste le estima prácticamente la misma velocidad que si tuviera un ADSL convencional, y comenzaría a preguntarse por qué ha contratado una conexión de alta capacidad si sigue recibiendo lo mismo… Algo parecido le sucedería si probara con el Test C durante la noche, ya que apenas le estimaría 9 Mbps.
Si, finalmente, nuestro usuario descubriera los tests B o D, o una mañana repitiera las pruebas con C, seguiría pensando que el servicio es deficiente (apenas da un 70% de la velocidad contratada), pero que “al menos se están esforzando en mejorarlo…” Al mismo tiempo, el usuario descubre extrañado cómo aplicaciones que utilizan más de una conexión TCP al mismo tiempo (p.e. programas de P2P) son capaces de alcanzar velocidades de descarga mucho mayores…
Ni qué decir tiene que si uno de estos tests de velocidad recopilara los resultados de todas sus medidas e hiciera un estudio sobre la velocidad de la banda ancha, podría llegar a la conclusión de que, cuanto mayores son las capacidades de los accesos, peor es el cumplimiento de la velocidad contratada… sin que este hecho llegara a detectarse nunca por las operadoras ni por los propios usuarios en condiciones normales de uso (p.e. utilizando aplicaciones multi-conexión).
¿Y qué pasaría si los usuarios fueran actualizando sus sistemas operativos o se las arreglaran para cambiar la configuración de su pila TCP para hacerla más eficiente? Pues que aún habría que comprobar si la ventana del servidor del test de velocidad es suficiente para estimar altas velocidades. Así, si añadimos a la tabla anterior una estimación indirecta de la ventana máxima de cada emisor, podremos estimar la máxima velocidad que puede medirse en cada caso:
Como puede apreciarse, el Test A seguiría infraestimando la capacidad de los accesos de banda ancha, mientras que los tests B y C andarían muy cerca de los límites de las ofertas más avanzadas de acceso. Sólo el Test D parece tener una configuración holgada de TCP.
Por último, cabría destacar que la notable diferencia en el RTT del Test C entre la mañana y la tarde-noche podría ser un indicador de problemas de saturación en el propio acceso del medidor de velocidad, pues, como puede apreciarse en la siguiente figura, los períodos de más RTT coinciden además con intervalos de abundantes pérdidas de paquetes (representadas en azul):
Una vez analizada la influencia de la configuración de ventana máxima en los extremos de la medida, dedicaremos el próximo post al estudio del otro gran elemento perturbador de estos tests: el crecimiento gradual de la ventana.
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
Tests de velocidad para banda ancha (III): TCP, la empresa de paquetería
Publicado el Agosto 19, 2008 por Francisco Javier Ramón
Archivado bajo Banda ancha, Futuro de Internet, Sociedad de la Información, Tecnologías
(Votos: 7. Media: 4.86/5) Loading ...Como vimos en el post anterior, los test de velocidad actuales consisten en la descarga de un contenido de tamaño conocido a través de una conexión TCP y la medición del tiempo empleado para completar la transferencia. Sin embargo, como ya adelantábamos, la influencia del protocolo TCP en la velocidad de descarga puede ser significativa en determinados casos y, en particular, cuando se trabaja con conexiones de alta capacidad.
Para comprender mejor las limitaciones que TCP impone a un test de velocidad, nos valdremos aquí de una analogía sencilla que nos permita analizar intuitivamente los factores que condicionan este tipo de transmisiones.
Supongamos una empresa de paquetería cuyo único cometido es transportar de forma fiable paquetes postales de un edificio a otro. Para ello, se vale de una cinta transportadora “de alta velocidad” que, en un recorrido circular —similar al de las cintas de equipaje de los aeropuertos—, va y vuelve entre los dos edificios.
Para llevar a cabo esta tarea con éxito, la empresa dispone de dos trabajadores, cada uno emplazado en un extremo, de manera que el primero (el “emisor”) se encargaría de depositar los paquetes por orden en la cinta, y el otro (el “receptor”) se encargaría de recogerlos en el otro extremo y pegar un post-it en su lugar, para que llegue a su compañero a modo de acuse de recibo, aprovechando así que la cinta es circular. De esta forma, en caso de que alguno de los paquetes se perdiera por el camino (cosas que pasan…), el “emisor” estaría en disposición de ensamblar otro paquete idéntico al extraviado y volverlo a poner sobre la cinta (como veis, se trata de una empresa de paquetería con habilidades sorprendentes).
En estas circunstancias cabe preguntarse: ¿cómo podrían coordinarse los dos extremos para aprovechar al máximo la velocidad de la cinta (es decir, para enviar el máximo número posible de paquetes por hora) a la vez que garantizan una entrega fiable?
Una forma posible de organizar estos envíos sería que el “emisor” enviase un paquete y esperase a la recepción del correspondiente acuse de recibo para poner el siguiente en la cinta (o, en su defecto, esperase un tiempo prudencial antes de reenviar el paquete presumiblemente “extraviado”). Sin embargo, si la distancia entre ambos edificios fuera considerable, con esta operativa no conseguiríamos aprovechar la capacidad de transporte de la cinta transportadora, toda vez que, a lo sumo, estaríamos introduciendo un paquete por cada vuelta completa de la cinta, de manera que casi toda su superficie de transporte quedaría desocupada.
Para mejorar la eficiencia de este proceso, en lugar de depositar un solo paquete en la cinta y esperar su acuse de recibo para cargar el siguiente, la empresa de paquetería decide que puedan cargarse 2 paquetes sin que se haya recibido aún su confirmación y, una vez se reciba el acuse de recibo del primero, se vuelva a depositar un nuevo paquete en la cinta, de manera que vuelva a haber 2 paquetes “en circulación”, y así sucesivamente. Una vez que la empresa descubre que, con esta sencilla medida, ha conseguido doblar el número de paquetes que era capaz de transportar en una hora, decide ir aumentando gradualmente este número de paquetes “en circulación”, de manera que a la semana siguiente se pasa de 2 a 4, la siguiente de 4 a 8, y así sucesivamente. De esta forma, cada semana la empresa consigue doblar su capacidad de transporte… hasta que llega a trabajar con un número tan grande de paquetes “en circulación” que consigue llenar completamente el espacio de la cinta (al menos, en su camino de ida). Una vez alcanzado este punto de “saturación”, la empresa entiende que está aprovechando al máximo la velocidad de la cinta transportadora pues, por cada paquete que se esté introduciendo en un extremo, la cinta estará entregando otro al receptor, y éste, a su vez, estará colocando un nuevo acuse de recibo que, más adelante, provocará que se deposite un nuevo paquete al ritmo adecuado… En estas condiciones de funcionamiento, nos encontramos con que:
- El sistema está trabajando de forma óptima, y la única forma de aumentar el ritmo al que se transportan paquetes pasa por aumentar la velocidad de la cinta.
- En caso de que algún día aumentara la longitud de la cinta transportadora (porque hubiera que enviar paquetes a un edificio más lejano) sería necesario un nuevo aumento de los paquetes “en circulación” para volver alcanzar la máxima eficiencia.
Como ya habrá deducido el lector, en el caso de un protocolo de transporte como TCP las cosas funcionan de una forma muy parecida:
- La velocidad de la cinta transportadora equivale al ancho de banda disponible.
- Los paquetes postales que viajaban por la cinta son ahora paquetes de información que se transmiten por la red.
- Los dos trabajadores que se ocupaban de cargar y descargar paquetes al ritmo adecuado son ahora los dos extremos del protocolo TCP (el emisor y el receptor, respectivamente).
- Así mismo, el papel que jugaban los post-it que se depositaban en la cinta lo desempeñan ahora paquetes especiales de asentimiento, ACK, que envía el receptor al emisor para ir confirmando la correcta recepción de paquetes de datos.
- La longitud de la cinta (dependiente de la distancia entre los edificios) equivale aquí al RTT, que es el tiempo necesario para transportar un paquete de un extremo a otro y que llegue su correspondiente ACK de vuelta.
- El número máximo de paquetes “en circulación” se denomina en TCP “ventana” y, al igual que sucedía en el ejemplo anterior, es un parámetro fundamental para su correcto funcionamiento con altas velocidades.
- El tanteo inicial de la empresa hasta encontrar un número adecuado de paquetes “en circulación”, equivale a un procedimiento análogo al que existe en TCP, denominado slow start, por el que se va aumentando gradualmente la ventana (y, con ella, el caudal de la conexión) hasta detectar una situación de saturación.
En definitiva, al igual que sucedía en el ejemplo anterior, nos encontramos con que es necesario que el parámetro de ventana sea el adecuado para que, en las condiciones de RTT que haya en cada momento, TCP pueda aprovechar al máximo el ancho de banda disponible. Así mismo, nos encontramos con que, a causa de este proceso inicial de “tanteo”, la conexión no alcanza su máximo caudal hasta que no ha transcurrido un cierto tiempo, tanto mayor cuanto mayor sea la velocidad máxima que puede alcanzarse en la línea.
Como puede intuirse fácilmente, el impacto que estos dos fenómenos tienen en el resultado del test puede llegar a ser muy relevante a altas velocidades. A analizar estas implicaciones y los efectos que provocan en algunos de los tests de velocidad más populares, dedicaremos las próximas entregas.
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
Tests de velocidad para banda ancha (II): ¿Cómo funciona un test de velocidad?
Publicado el Agosto 18, 2008 por Francisco Javier Ramón
Archivado bajo Banda ancha, Futuro de Internet, Sociedad de la Información, Tecnologías
(Votos: 8. Media: 4.75/5) Loading ...Los tests de velocidad actuales, por razones de simplicidad, basan su estimación en medir el tiempo que el usuario necesita para descargar un contenido de tamaño conocido a través de una conexión TCP. Así, dividiendo el tamaño del contenido por el tiempo invertido en su descarga, se determina el caudal medio que tuvo esa conexión y este valor se emplea como estimador del ancho de banda disponible en el acceso del usuario. Para facilitar la realización del test, el proceso de descarga se oculta al usuario tras una interfaz sencilla (en flash o java), que sirve luego para presentar los resultados de la prueba de una manera amigable.
Una variante de esta metodología es la del llamado “test de Ookla”, donde se toman numerosas muestras a lo largo de la descarga (contando los bytes transferidos en cada intervalo), se descartan muestras “extrañas”, y al final se hace un promedio de todas esas estimaciones parciales. Esta variante, que permite ir ofreciendo al internauta “resultados intermedios” a modo de velocímetro, es la que emplean gran parte de las webs españolas que ofrecen medidores de velocidad.
Hay que señalar que estas metodologías se centran, por tanto, en estimar el ancho de banda que “llega” a la aplicación y no el realmente provisto por la red (que incluiría el transporte de todas las cabeceras de enlace, de IP, de TCP, etc.). Si bien la diferencia entre ambas magnitudes puede llegar a ser de algunos puntos porcentuales, como primera aproximación suele considerarse ésta una fuente de error “controlada”, ya que es de un orden de magnitud relativamente modesto y, casi siempre, es constante en porcentaje respecto a la capacidad del acceso que se quiera medir. Sin embargo, para que lo anterior sea cierto, es necesario garantizar que el usuario no está utilizando ninguna otra aplicación durante la realización de la prueba (por ejemplo, descargándose un fichero al mismo tiempo). Esta condición será especialmente difícil de verificar completamente si se trata de un test de velocidad accesible al gran público a través de Internet.
No obstante, la principal fuente de error en tests basados en esta metodología procede del impacto que el propio protocolo TCP y sus mecanismos de control de flujo tienen en la velocidad de descarga cuando la red de acceso es de alta capacidad. Así, factores como la configuración de TCP en el servidor de medidas y en el ordenador del usuario, la latencia entre ambos extremos o el tamaño de la descarga pueden tener un impacto determinante en el máximo caudal que puede alcanzarse en la conexión TCP de la prueba y, por tanto, en la velocidad que finalmente se estima para ese acceso.
Teniendo en cuenta la importancia de estos factores como principales fuentes de error en los tests de velocidad más populares, merecerá la pena revisarlos con más atención para entender cómo TCP puede llegar a comportarse de forma imprevista. A revisar el comportamiento de este protocolo y a señalar sus limitaciones para un test de velocidad, dedicaremos el próximo post. Para ello nos valdremos de un símil sencillo con una empresa de paquetería empeñada en aprovechar al máximo su nueva cinta transportadora “de alta velocidad”.
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, tests de velocidad, xDSL
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
