Latencia: Por qué existe y cómo funcionan los modos fastpath e interleaving

Latencia: Por qué existe y cómo funcionan los modos fastpath e interleaving

Todos los usuarios que tenemos hoy en día una línea de internet en nuestra vivienda, demandamos que sea de calidad y que se cumpla la velocidad contratada. Pero a veces, a pesar de llegar la velocidad contratada, puede que no sea suficiente para llegar a acceder a todas las cosas que esperamos de nuestra línea.

¿Cuantos de vosotros no sufrís ralentizaciones, cortes en el juego, y un gran retardo en las partidas online? Seguro que alguna vez incluso habéis sidos expulsados de partidas por tener un lag alto.

Hoy en RedesZone vamos a hablar como introducción de qué factores son los que producen el lag en la línea y enfrentaremos los dos tipos de latencias que a día de hoy estan más extendidos, el modo fastpath, que como bien sabéis solo Jazztel lo activa en España, y el modo interleaving, cuyo gran precursor se ha convertido Movistar. Veremos de qué manera estos dos modos de latencia pueden llegar a influir en el rendimiento de nuestra conexión.

Ping y lag

Antes de nada me gustaría hacer una pequeña aclaración de términos. Actualmente la gente puede llegar a pensar que el ping de la línea es el retardo que existe en ésta y eso es un error. El ping es el programa que se utiliza para comprobar el estado de la conexión entre dos ordenadores y asociado a esto, se puede también comprobar el tiempo de respuesta, es decir, el tiempo que desde el PC emisor envía la petición de ping, hasta que recibe la confirmación del otro PC. Por lo tanto el tiempo que transcurre desde que se envía la petición hasta que es recibida, recibe el nombre de lag o latencia.

Por lo tanto cuando nosotros hacemos un ping en la consola de comandos de Windows obtenemos un resultado que tiene como unidad los milisegundos (ms).

¿Por qué existe lag?

Como ya hemos visto anteriormente, el lag es un retardo temporal que se produce al transmitir una información por un medio. El lag puede depender de numerosos factores, pero los principales son:

- El tamaño de los bufferes y el tamaño de los paquetes.

- La cantidad de “intermediarios” que existan entre el emisor y el receptor.

- El medio o el material por el cual se transmite y el estado en el que este se encuentra.

- Protocolos que controlan la transmisión.

Si en una conexión de red local existen varios equipos conectados por varios switch o AP y cada uno de estos esta conectado entre sí, el equipo que menos latencia tendrá será el que pase por menos equipos y el que esté conectado por red cableada, ya que las conexiones inalámbricas poseen más latencia debido a protocolos de control de errores que más adelante veremos detallados un poco más. Por lo que cuanto más intermediarios halla, peor.

Algo que seguro conocéis, es que dependiendo del medio en el cual se transmita habrá una menor o mayor latencia. Así, por ejemplo en conexiones de fibra óptica el lag es prácticamente nulo, sin embargo, si tenemos una conexión por par de cobre, el lag puede ser hasta tres veces más que en las conexiones bajo fibra óptica.

Incluso dentro del mismo medio puede haber distintas latencias, producidas por un mal estado. Por ejemplo en una conexión ADSL que tenga un par en mal estado puede ver empeorado su latencia de manera considerable llegando a ser incluso el doble que en una conexión con par en buen estado.

Los buffers de los dispositivos que intervienen en la conexión también pueden jugar un papel importante, ya que un buffer pequeño asociado a un gran tamaño de paquetes puede ser una combinación fatal, ya que estaría condicionando la transferencia de los paquetes llegando a producir un cuello de botella un gran retardo en la conexión producido por no tener capacidad para gestionar todos los paquetes que le llegan.

¿Por qué los protocolos influyen en la latencia?

Realmente los protocolos a pesar de existir para comprobar de que toda la comunicación y envío de datos vaya bien, tiene su lado negativo, y es que producen lag en las conexiones ya que el proceso de verificar si los datos están correctos o no y de establecer la conexión requiere un tiempo.

Seguro que alguno de ellos los conoceréis, como los protocolos TCP e IP. El primero de ellos se trata del Protocolo de Control de Transmisión, y el segundo es el Protocolo de Internet. Gracias a estos dos, los ordenadores hoy en día puede comunicarse unos con otros sin que todo el proceso sea un caos. Estos protocolos abarcan otros protocolos como HTTP, FTP, Telnet.

También tenemos el UDP, que se trata de un protocolo de envío de tramas que tiene una clara ventaja respecto a TCP, no tiene control de errores implementado, por lo que el tiempo empleado en el envío de datos es menor. Sin embargo al no tener corrección de errores la cantidad de datos que pueden llegar mal puede llegar a ser bastante más alta con respecto a TCP.

Además de estos protocolos existen otros contenidos en los anteriores, se llaman los protocolos de control de errores, y que garantizan que los datos recibidos en un equipo, sean los mismos que se han enviado por el otro equipo. Existen muchos protocolos, pero los que más os puedan sonar son el CRC, la utilización de bit de paridad, y el Checksum.

El CRC (Comprobación de Redundancia Cíclica) se basa en una función polinómica, al cual se le pasa como parámetro un conjunto de datos. Esta función retorna un valor asociada a ese conjunto de datos, por lo que cuando llega al receptor, el CRC vuelve a realizarase y si el resultado no coincide podríamos estar ante un error o bien en los datos enviados que se han corrompido por el camino, o bien el resultado obtenido en el emisor se ha alterado durante la transmisión.

El bit de paridad es algo mas sencillo que el CRC y se basa en la colocación de un bit a 1 o 0 en el paquete de datos enviados, dependiendo de la cantidad de 1 que tenga el paquete. De esta forma si nos encontramos la utilización del bit de paridad par, este será 0 siempre que la cantidad de 1 sea par, y el bit de paridad impar, será 1 cuando el número de 1 contenidos en el paquete sea impar.

Por lo tanto si enviamos un paquete que posee 10 dígitos y 8 de los cuales son 1, el bit de paridad a 0, y el receptor recibe un paquete con 10 dígitos pero solo 5 son 1, existe un error ya que el bit de paridad es 0, por lo tanto el paquete es corrupto.

El Checksum es similar al CRC, con los bits del paquete a enviar se realiza una suma y se obtiene un resultado, que también es enviado con

...