×

Aviso

Directiva de la UE acerca de la privacidad en comunicaciones electrónicas

Esta sede de Internet utiliza 'cookies' para gestionar la autenticación, la navegación y otras funciones. Si estás de acuerdo y aceptas que almacenemos 'cookies' en tu dispositivo, posiblemente tendrás una mejor experiencia de navegación. Si las rechazas, podrás seguir navegando por nuestra sede, pero no dejaremos 'cookies' en tu dispositivo y algunas características de las páginas podrían no presentarse adecuadamente.

Ver los documentos de la directiva de privacidad

Has rechazado las 'cookies'. Esta decisión puede ser revertida.

Acelerando la transferencia de ficheros audiovisuales (2)

En una nota anterior titulada Acelerando la transferencia de ficheros audiovisuales, que es de las que más interés y comentarios han suscitado, me refería a la aceleración de la transferencia de archivos audiovisuales entre ubicaciones remotas. Volviendo al mismo tema, voy a intentar responder de una forma sencilla a alguna de las preguntas que he recibido.

Partiremos de un ejemplo similar al que utilizaba en el caso anterior.

Supongamos que formamos parte de una empresa de postproducción de Barcelona, Bilbao, Coruña, Madrid, Sevilla o Valencia. Nuestro supervisor de efectos visuales (VFX) está en otra ciudad, en un rodaje al que se ha llevado un ordenador portátil con una aplicación de etalonaje y otra de composición para ir haciendo pruebas y preparando algunos planos, y nuestro cliente está en una tercera ciudad. El supervisor de VFX quiere enviarnos un par de planos, unos 10 GB en total, y nosotros queremos preparar algo para enseñárselo a nuestro cliente, que quiere tomar algunas decisiones que podrían afectar al rodaje. Disponemos de una buena conexión a Internet, de 1 Gb/s. Llamamos a nuestro cliente y le decimos que mañana por la mañana podremos enviarle algo.

RJ45

Cómo prever cuánto va a tardar en transferirse el material

¿Podemos prever cuánto va a tardar en llegarnos el material? ¿Podemos prever cuánto va a tardar en llegarle a nuestro cliente?

Siguiendo la línea de la nota anterior, sabemos que los problemas de latencia y de pérdida de paquetes pueden afectar negativamente a la velocidad de transferencia, incrementando, incluso demasiado para nuestros propósitos, el tiempo necesario para llevarla a cabo con éxito. Pero podemos hacer una previsión.

Buscando respuestas

Algunas de las cuestiones que surgieron a raíz de la publicación de la nota titulada Acelerando la transferencia de ficheros audiovisuales venían a preguntar, grosso modo, en qué casos un sistema de transferencia de ficheros que utilice el User Datagram Protocol (UDP), en lugar del Transmission Control Protocol / Internet Protocol (TCP/IP), que es el utilizado en una transferencia por FTP, puede suponer verdaderamente una ventaja significativa.

En el caso de la utilización de FileCatalyst, la solución comercial a la que nos referíamos en aquella nota, la aceleración de la transferencia no se debe únicamente a que se esté llevando a cabo por UDP en lugar de por TCP, ya que también hace uso de otras técnicas, como la utilización de varios flujos de datos simultáneos y de algoritmos de compresión, pero en el análisis que sigue nos vamos a limitar a intentar entender la diferencia entre transferir un archivo por TCP, por ejemplo a través de FTP, y transferirlo haciendo uso de UDP, y cómo eso afecta a la velocidad de la transferencia.

Tomemos nuestro fichero de 10 GB y nuestra conexión de 1 Gb/s. Otra información que necesitamos es el tamaño de la TCP Receive Window y el Round Trip Time (RTT). Normalmente, en equipos con sistema operativo Windows, la TCP Receive Window es de 64 KB, así que vamos a utilizar ese valor en nuestro ejemplo (es posible variar el tamaño de la TCP Receive Window y puede llegar a ser de hasta 1 GB, aunque no es habitual). Ya sólo nos falta el RTT, que va a variar en función del destino y obtendremos utilizando el comando ping.

Para saber la velocidad máxima de transferencia de nuestra conexión, dividiremos la TCP Receive Window por el RTT.

Para saber el tiempo mínimo que necesitará nuestro fichero para transferirse en condiciones ideales, dividiremos su tamaño por la velocidad máxima de transferencia.

Para ser realistas y no generar falsas expectativas, sabiendo que las condiciones reales no se corresponden con las ideales, conviene estimar que el tiempo realmente necesario para la transferencia puede ser aproximadamente el doble del resultado del cálculo anterior.

Volvamos al principio

Supongamos que formamos parte de una empresa de postproducción de Barcelona, Bilbao, Coruña, Madrid, Sevilla o Valencia. Nuestro supervisor de VFX está en Karachi, en un rodaje al que se ha llevado un ordenador portátil con una aplicación de etalonaje y otra de composición para ir haciendo pruebas y preparando algunos planos, y nuestro cliente está en São Paulo. El supervisor de VFX quiere enviarnos un par de planos, unos 10 GB en total, y nosotros queremos preparar algo para enseñárselo a nuestro cliente, que quiere tomar algunas decisiones que podrían afectar al rodaje. Disponemos de una buena conexión, de 1 Gb/s.

Envío de material audiovisual

Los cálculos

Para conocer el RTT entre nuestra empresa y el ordenador de origen en Karachi haremos un ping entre nuestra ubicación y un servidor que se encuentra en Karachi, en el mismo lugar desde el que nos van a enviar el fichero, y que vamos a suponer que aloja la página http://www.ejemplo.pk, por lo que se llama ejemplo.pk:

ping -c 10 -s 1472 ejemplo.pk

El ping se ejecutará 10 veces con un paquete de 1.500 bytes (1.472 + 28, que es el tamaño de la cabecera del paquete), ya que seguramente ese será el tamaño máximo que puedan tener los paquetes que vayan a enviarse. Si el ping no se lleva a cabo, volveremos a ejecutarlo indicando un valor inferior.

Cuando finalice el ping, miraremos el valor promedio (avg) del RTT, que aparecerá en la parte inferior expresado en milisegundos (junto al valor mínimo y al valor máximo).

Supongamos que ese valor es de 150ms.

  • Tenemos un fichero de 10 GB.
  • Tenemos una conexión de 1 Gb/s.
  • Tenemos una TCP Receive Window de 64KB.

64 * 1.024 = 65.536 bytes.

65.536 * 8 = 524.288 bits.

  • Tenemos un RTT de 150ms.

150 / 1.000 = 0,15 segundos.

Para saber la velocidad máxima de transferencia de nuestra conexión, dividiremos la TCP Receive Window por el RTT:

524.288 / 0,15 = 3.495.253 bits/s = 3,4 Mb/s

Es decir, aunque tengamos una conexión de 1 Gb/s, la velocidad máxima de transferencia que vamos a obtener (según los datos de nuestro ejemplo) es de 3,4 Mb/s, por lo que nuestro fichero de 10 GB tardará en transferirse (en unas condiciones ideales) 6 horas con 41 minutos, y no sería extraño que tardase unas 12 horas.

Para disponer del RTT entre nuestra empresa y la de nuestro cliente que está en Brasil haremos un ping entre nuestra ubicación y el servidor de nuestro cliente, que vamos a suponer que aloja la página http://www.ejemplo.br, por lo que se llama ejemplo.br:  

ping -c 10 -s 1472 ejemplo.br

Igual que en el caso anterior, el ping se ejecutará 10 veces con un paquete de 1.500 bytes. Si el ping no se lleva a cabo con el valor 1.472, volveremos a ejecutarlo indicando un valor inferior.

Cuando finalice el ping, miraremos el valor promedio (avg) del RTT.

Supongamos que ese valor es de 180ms.

  • Tenemos un fichero de 10 GB.
  • Tenemos una conexión de 1 Gb/s.
  • Tenemos una TCP Receive Window de 64 KB:

64 * 1.024 = 65.536 bytes.

65.536 * 8 = 524.288 bits.

  • Tenemos un RTT de 180ms.

180 / 1.000 = 0,18 segundos.

Para saber la máxima velocidad de transferencia de nuestra conexión, dividiremos la TCP Receive Window por el RTT:

524.288 / 0,18 = 2.912.711 bits/s = 2,7 Mb/s

Es decir, aunque tengamos una conexión de 1 Gb/s, la velocidad máxima de transferencia que vamos a obtener (según los datos de nuestro ejemplo) es de 2,7 Mb/s, por lo que nuestro fichero de 10 GB tardará en transferirse (en unas condiciones ideales) 8 horas con 25 minutos, y no sería extraño que tardase unas 16 horas.

Las cifras

Siguiendo con nuestro ejemplo, en unas condiciones ideales, utilizando una transferencia por FTP, nuestro archivo de 10 GB tardaría unas 6 horas con 41 minutos en llegarnos desde Karachi y nosotros emplearíamos unas 8 horas con 25 minutos en hacérselo llegar a nuestro cliente (una vez hubiésemos practicado sobre él las modificaciones que hubiésemos querido), lo que nos da un total de 15 horas con 6 minutos empleados en la transferencia del fichero en unas condiciones ideales, que podrían convertirse en realidad en unas 30 horas.

Si la transferencia pudiese llevarse a cabo a la velocidad nominal de la línea, que en nuestro ejemplo es de 1 Gb/s, estaríamos hablando de unos 2 minutos con 40 segundos.

De 15 horas con 6 minutos (que podrían ser en realidad unas 30 horas) a 2 minutos con 40 segundos, la diferencia es notable.

Casos en los que la transferencia utilizando UDP no supone una ventaja

¿Resulta la transferencia a través de UDP más ventajosa en todas las ocasiones que la transferencia a través de TCP/IP? ¿Puede haber casos en los que la transferencia a través de UDP no sea una ventaja? ¿Puede haber casos en los que resulte indiferente utilizar un protocolo u otro?

Vamos a suponer ahora que nuestra conexión es de 10 Mb/s (en lugar de 1 Gb/s) y queremos transferir nuestro fichero de 10 GB entre Barcelona y Bilbao.

Igual que en los casos anteriores, para calcular el RTT entre nuestra sede en Barcelona y nuestra sede en Bilbao haremos un ping entre nuestra ubicación y el servidor de destino, que vamos a suponer que aloja la página http://www.ejemplo.es, por lo que se llama ejemplo.es:  

ping -c 10 -s 1472 ejemplo.es

Igual que los casos anteriores, el ping se ejecutará 10 veces con un paquete de 1.500 bytes. Si el ping no se lleva a cabo con el valor 1.472, volveremos a ejecutarlo indicando un valor inferior.

Cuando finalice el ping, miraremos el valor promedio (avg) del RTT.

Supongamos que ese valor es de 50 ms.

  • Tenemos un fichero de 10 GB.
  • Tenemos una conexión de 10 Mb/s.
  • Tenemos una TCP Receive Window de 64 KB:

64 * 1.024 = 65.536 bytes.

65.536 * 8 = 524.288 bits.

  • Tenemos un RTT de 50ms.

50 / 1.000 = 0,05 segundos.

Para saber la velocidad máxima de transferencia de nuestra conexión, dividiremos la TCP Receive Window por el RTT:

524.288 / 0,05 = 10.485.760 bits/s = 10 Mb/s

Es decir, tenemos una conexión de 10 Mb/s y la velocidad máxima de transferencia que vamos a obtener (según los datos de nuestro ejemplo) es precisamente de 10 Mb/s, por lo que nuestro fichero de 10 GB tardará (en unas condiciones ideales) 2 horas con 16 minutos, aunque no sería extraño que tardase unas 4 horas. En cualquier caso, el RTT no estará afectando de forma visible a nuestra velocidad de transferencia.

Resumiendo

Utilizando un sistema de transferencia de ficheros que haga uso del Transmission Control Protocol / Internet Protocol (TCP/IP), como el FTP, la velocidad de transferencia puede verse limitada significativamente por el Round Trip Time (RTT) independientemente de la velocidad nominal de nuestra conexión.

Utilizando un sistema de transferencia de ficheros que haga uso del User Datagram Protocol (UDP), en lugar del Transmission Control Protocol / Internet Protocol (TCP/IP), podemos sortear algunos problemas inherentes a los valores altos de RTT que se dan en las conexiones entre puntos distantes y llevar a cabo transferencias de ficheros a una velocidad próxima a la velocidad nominal de nuestra conexión también en los casos en los que el RTT afecta negativamente a las velocidades reales de transferencia.

Antes de implantar un sistema de transferencia por UDP para substituir un sistema de transferencia por TCP/IP, y con el fin de no generar falsas expectativas, es importante que calculemos y valoremos las mejoras que el sistema de transferencia por UDP puede introducir en nuestro flujo de trabajo.

Algunas soluciones de transferencia de ficheros a alta velocidad, como FileCatalyst, aprovechan las ventajas del uso del UDP, que combinan con otras técnicas (como la utilización de varios flujos de datos simultáneos, algoritmos de compresión sin pérdida y las transferencias Delta), para acelerar las transferencias.

En algunas ocasiones, la aceleración de las transferencias es el único medio para llevar a cabo en las condicionaes adecuadas un trabajo colaborativo entre personas o empresas que se encuentran en ubicaciones que están distantes entre sí.

Si deseas recibir información adicional acerca de la aceleración de la transferencia de ficheros audiovisuales y FileCatalyst, envía un mensaje a Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo..

 

Galería de imágenes

Acerca de mí

Presto servicios de asistencia técnica sobre tecnología audiovisual, imparto cursos técnicos y de operación y apoyo en labores técnicas y comerciales a empresas que ofrecen tecnología y servicios relacionados con la imagen en movimiento.

Desde el 1 de Septiembre de 2017 presto todos mis servicios profesionales a través de la empresa PROVITEC Instalaciones y Sistemas.

Mi perfil en LinkedIn

Has aceptado que dejemos 'cookies' en tu dispositivo. Esta decisión se puede revertir.