Ir al contenido principal
"Acabamos de pasar de un T1 (1.544 mbps) a un T3 (44.736 mbps) así que, ¿por qué sigue llevando 90 minutos copiar ese archivo?"

 

La respuesta simple es que más capacidad no es lo mismo que bytes más rápidos. Si aumenta su capacidad en casi 29 (44.736 / 1.544) veces puede ser capaz de copiar 29 archivos en los mismos 90 minutos, pero probablemente no podrá copiar ese archivo más rápido. Ya mencioné esto el año pasado en el blog titulado "Problemas de rendimiento y latencia de la aplicación", pero creo que las transferencias de archivos y copy_file requieren un blog más enfocado.

 

La clave tiene que ver con el tamaño de las ventanas, es decir, cuántos bytes puede enviar el host/aplicación remitente sin tener que detenerse y esperar un acuse de recibo del host/aplicación receptor. Algunas aplicaciones como el FTP no tienen un acuse de recibo de la capa de aplicación y dependen del TCP. En este caso, el tamaño de la ventana se basa en lo que anuncia la capa TCP del host remoto, hasta 64K bytes que es el máximo que soporta STCP. Algunas aplicaciones tienen una ventana de capa de aplicación, para estas aplicaciones la ventana límite es la más pequeña de las ventanas de TCP y de la aplicación.
El rendimiento máximo se calcula como

 

W / RTT = T
Donde
W es el tamaño de la ventana en bytes
RTT es el tiempo de viaje de ida y vuelta en segundos
T es el rendimiento en bytes por segundo
El tiempo de ida y vuelta es el que se necesita para enviar algunos datos y obtener el reconocimiento. Para grandes distancias, es decir, a través del país, ese tiempo se basa principalmente en la distancia que deben recorrer los bytes y la velocidad de procesamiento de todo el equipo de red entre los puntos finales. La velocidad de procesamiento del host receptor, el tamaño de los paquetes (valor TCP MSS, véase "Una forma fácil de mejorar el rendimiento a través de las subredes") y, por supuesto, el ancho de banda del enlace más lento desempeñan papeles más pequeños.

 

Por ejemplo, si el RTT es de 0,050 segundos y la ventana es de 64K, el rendimiento máximo será de 1.310.720 bytes por segundo (64 * 1024 / 0,050). Mientras la capacidad no utilizada del enlace sea mayor que el rendimiento, el aumento de la capacidad no acelerará el tiempo de transferencia.
T es el máximo rendimiento posible. Nada de lo que hagas (excepto aumentar la ventana o reducir el RTT) puede hacer que las cosas vayan más rápido PERO las condiciones hostiles de la red pueden hacer que las cosas vayan considerablemente más despacio.

 

Estimar el tiempo de transferencia es sólo dividir el tamaño del archivo por el rendimiento

 

F/ W * RTT = Ti
Donde
F es el tamaño del archivo en bytes
W es el tamaño de la ventana en bytes
RTT es el tiempo de viaje de ida y vuelta en segundos
Ti es el tiempo en segundos para transferir el archivo

 

OSL tiene un tamaño de ventana de aplicación de 4K, el sistema de archivos OpenVOS reporta los tamaños de los archivos en bloques de 4K bytes, así que para estimar el tiempo de copia de un archivo entre dos sistemas OpenVOS usando el comando copy_file es simplemente

 

F * RTT = Ti
Donde
F es el tamaño del archivo en bloques
RTT es el tiempo de viaje de ida y vuelta en segundos
Ti es el tiempo en segundos para transferir el archivo

 

En un enlace con un RTT de 0.050 segundos le tomará a OSL un poco más de 41 minutos copiar un archivo de bloque de 50.000 (50.000 * 0.05). El máximo rendimiento será de 81.920 bytes por segundo (4096 / 0.050). Mientras la capacidad de red no utilizada de su enlace sea superior a 81.920 bytes por segundo, la adición de capacidad no reducirá el tiempo necesario para copiar el archivo.

 

La forma más simple de medir el tiempo de viaje de ida y vuelta es con ping. Desafortunadamente, el ping no te da un número para el RTT, sino varios números y los números pueden variar significativamente, por ejemplo:

 

ping 172.16.1.80
Pinging host 172.16.1.80 : 172.16.1.80
ICMP Echo Reply:TTL 53 time = 418 ms
ICMP Echo Reply:TTL 53 time = 107 ms
ICMP Echo Reply:TTL 53 time = 91 ms
ICMP Echo Reply:TTL 53 time = 100 ms
Host 172.16.1.80 replied to all 4 of the 4 pings
ready 12:03:15

 

Si está interesado en calcular el mejor rendimiento posible, use el número más bajo. Si está interesado en una estimación razonable de lo que debe esperar use una cuenta ping de 10, tire los dos números más altos y los dos más bajos y promedie el resto.

 

ping 172.16.1.80 -count 10
Pinging host 172.16.1.80 : 172.16.1.80
ICMP Echo Reply:TTL 53 time = 89 ms
ICMP Echo Reply:TTL 53 time = 96 ms
ICMP Echo Reply:TTL 53 time = 95 ms
ICMP Echo Reply:TTL 53 time = 105 ms
ICMP Echo Reply:TTL 53 time = 186 ms
ICMP Echo Reply:TTL 53 time = 87 ms
ICMP Echo Reply:TTL 53 time = 90 ms
ICMP Echo Reply:TTL 53 time = 90 ms
ICMP Echo Reply:TTL 53 time = 89 ms
ICMP Echo Reply:TTL 53 time = 96 ms
Host 172.16.1.80 replied to all 10 of the 10 pings
ready 12:12:39
calc 96 + 95 + 90 + 90 + 89 + 96
556
ready 12:12:49
calc 556 / 6
92.6666666666667
ready 12:12:57

 

Como dije antes, una red hostil puede retrasar las cosas significativamente. Los tiempos muertos de los ping son una indicación de esto. Así que cualquier tiempo muerto significa que estos cálculos son probablemente muy optimistas. Las transferencias también pueden ser ralentizadas por discos ocupados y/o CPUs que impiden al emisor leer y enviar los datos lo más rápido posible o hacen que el receptor lea los datos más lentamente que su velocidad de llegada, retrasando los acuses de recibo de las aplicaciones (aumentando el tiempo de viaje de ida y vuelta) y posiblemente llenando los buffers de recepción TCP lo que hace que el host emisor deje de transmitir. La única forma de saber si alguna de estas condiciones se aplica es con un rastreo de paquetes.