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

Escrito por Adrián Crespo
Redes
9

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 los datos.  Cuando los datos los recibe el receptor, se vuelve a realizar el Checksum, y si no coincide con el dato de la suma obtenido antes del envío, se ha producido un error.

Después de detectar los errores en los paquetes no queda otra forma de corregir el error que pidiendo un reenvío de la información corrupta. Por lo que imaginad la cantidad de tiempo que puede perderse, corrigiendo y comprobando.

Vamos entonces a lo importante, como funciona el Fastpath y el Interleaving para que haya tanta diferencia de latencia entre ambos

Fastpath vs Interleaving

Actualmente en nuestras conexiones ADSL disponemos de una implementación punto a punto. Es decir, vosotros tenéis en vuestras casas un router (ATU-R), pero en la central o en el DSLAM del muxfin disponemos del hermano del equipo que se encuentra en nuestro domicilio (ATU-C). Para que exista una comunicación entre ambos equipos es necesario que en ATU-C se configuren estos parámetros, es decir que se active el modo Fastpath o el modo Interlaving.

– Modo interleaving

Se trata de un mecanismo de corrección de errores basado en la interpolación de las distintas partes en que se divide una trama. Para que nos entendamos mejor, la trama se divide en subtramas más pequeñas, y son enviadas en desorden para que después de llegar al receptor, estas son reordenadas de nueva en su orden original. El motivo por el cual se hace esto es fácil, si una trama se corrompe, habría que reenviar toda la información de nuevo, mientras que de esta forma, se puede dañar una subtrama que se puede tratar de aproximar a la original o corregirla por completo gracias a los mecanismos de corrección comentados anteriormente. En el proceso de interpolación se cree que se puede llegar a perder una media que se encuentra en torno a 30-40 ms.

 – Modo fastpath

Se trata de la supresión del modo Interlaving ya que sería redundante y visto de esta manera absurdo ya que TCP implementa una función de corrección de errores que no deja que llegue ningún bit erróneo ya que se encarga de solicitar un nuevo reenvío de la información errónea. Al no tener que ordenar las tramas como en interleaving, tanto ATU-C como ATU-R no tienen que hacer uso de buffers y esperar a que llegue toda la información para ordenarla por lo que todo se traduce en un mayor rapidez.

 Entonces ¿Cuál es mejor?

La respuesta es obvia, fastpath consigue un mayor rendimiento debido a que se invierte menor tiempo en la trasnferencia de datos. Ahora todos estaréis pensando por qué Movistar no activa al fastpath de una vez. Tenéis toda la razón pero basándonos en explicaciones anteriores los clientes de Imagenio no podrían tener activado el Fastpath.

La razón es sencilla, ahora los canales emiten utilizando el protocolo RTP, antes utilizaban UDP. Ambos son protocolos que no posee un sistema de corrección de errores como TCP por lo que suprimir el interleaving en estos usuarios sería letal y dilapidaría la IPTV a día de hoy, ya que la calidad de la imagen sería muy deficiente.

A pesar de esto yo soy de los que pienso que Movistar debería activar a sus clientes de ADSL sin Imagenio el fastpath, como ya hace Jazztel desde hace tiempo. Sin embargo el uso de interleaving combinado con FTTH da un rendimiento mejor que el fastpath de Jazztel en cobre. Por lo que la latencia que tenemos en nuestra conexión es una mezcla de todas las cosas que la conforman.


Noticias relacionadas

Comentarios


9 comentarios
  1. Ethiel 07 Oct, 11 12:50

    Coxonudo e interesante. 😀

    Responder
    0
  2. Aleix 07 Oct, 11 13:23

    me ha aclarado bastantes cosas que ignoraba, gracias.

    Responder
    0
  3. Pedro 07 Oct, 11 17:45

    Muy bien por la esplicacion, cada dia os mejorais.
    Pienso como tu, movistar deberia dar la opcion de activar el fastpath al usuario que lo pida,yo estoy con Jazztel indirecto y no tengo fastpath y se nota al jugar online.

    Responder
    0
  4. hispalis70 07 Oct, 11 18:41

    Muy buen articulo y muy bien explicado. 😉

    Responder
    0
    1. Adrián Crespo 07 Oct, 11 18:49

      Gracias ! 🙂

      Responder
      0
  5. Sergio De Luz 07 Oct, 11 19:14

    Adrián que está hecho un crack 😀 😀 😀

    Responder
    0
  6. Macià Marquès 07 Oct, 11 23:26

    Amén, Adrián se ha pegado la currada padre, enhorabuena por el artículo compy

    Responder
    0
  7. Johnny 08 Oct, 11 0:02

    Sublime.

    Responder
    0
  8. Tor 21 Oct, 12 16:53

    Yo tenía Movistar FTTH 100MB de bajada y 10MB de subida y el ping lo he llegado a tener en 12 ms.
    Ahora que me mudé, tengo VDSL de Jazztel de 30MB de bajada y 3MB de subida, y la mejor manera que pude imaginar (además, no me querían cablear desde el PTR hasta el cuarto del PC, ya que estaba a unos 60 metros, y me querían cobrar 250 euros) fue a través de dos PLC y en la habitación un switch ethernet RJ45 de 8 puertos (7, quitando el entrante).
    No ve va mal, pero sincroniza en la entrada de línea, el router, a 30 MB clavados, pero lo máximo que conseguí en mi PC fueron 24 MB. Y eso fue bastante puntual. Normalmente va a 17 o 18 MB. Y ahora no se qué pasó pero desde el viernes bajó unos 5 o 6 MB. Y ayer estuvo yendo a 1 MB. Algo está pasando.
    Con lo cómoda que era la FTTH de 100 MB.
    Eso es lo que tiene el par de cobre.

    Un saludo a todos.

    Responder
    0