¿Incrementar el ancho de banda en un enlace de, digamos, 1mb a 30mb reduce el RTT?
He encontrado una respuesta diciendo que no. ¿Alguien puede explicar?
Además, ¿cuáles son los mejores mecanismos para reducir la RTT?
protocol-theory
latency
NetworkNinja
fuente
fuente
Respuestas:
En resumen, sí; está cambiando el retraso de serialización ; a 1 Mbps, el retraso de serialización no es trivial.
Compare el retraso de serialización para un paquete de 1500 Bytes a 1Mbps y 30Mbps:
Recuerde también que esos son números unidireccionales; debes doblarlos cuando consideres RTT. Si le importa la diferencia de 11.6 milisegundos en cada dirección a 1500 bytes es otra pregunta, pero estrictamente hablando puede influir en RTT con la velocidad del enlace.
fuente
No, aumentar el ancho de banda no reduce RTT estrictamente hablando. ¡Digo "estrictamente hablando" porque depende de lo que estés midiendo!
Escenario 1: la capa física
Dada la siguiente topología simple que es fácil de seguir, una conexión Ethernet de cobre que se ejecuta a 1 Mbps con una MTU de 1500 bytes entre dos dispositivos con un cable de 10 metros, tiene el mismo RTT (el tiempo que tomaría un paquete de solicitud de eco ICMP para viajar del dispositivo 1 al dispositivo 2 y el mensaje de respuesta de eco ICMP para viajar del dispositivo 2 de regreso al dispositivo 1) como una conexión Ethernet de cobre de 10/30/50/100 mbps entre ellos con una MTU de 1500 bytes en el mismo cable de 10 metros.
Esto se debe a que el "retraso" de la señal en el cable de cobre está relacionado con su constante dialéctica ( permitividad relativa ). Vea esas dos páginas de Wikipedia para obtener información adicional sobre la física que están fuera de alcance aquí.
Esencialmente, el "tiempo de vuelo" de las señales eléctricas por el cable de cobre es la misma velocidad para una conexión de 10 Mbps y 1000 Mbps cuando se utiliza el mismo cable Cat5e de longitud y grado. La diferencia es que con una conexión de 10Mbps, los datos se codifican en el cable con menos frecuencia que una conexión de 100Mbps, por lo que hay brechas más pequeñas entre los bits de datos a medida que se colocan en el cable (esto se llama retraso de serialización ). Estos dos artículos de Wikipedia amplían aún más estos conceptos: tiempo de bits y tiempo de ranura .
Escenario 2: Capa 4 y superior (ejemplo de TCP)
Dada la siguiente topología de ejemplo, una conexión Ethernet de cobre que se ejecuta a 1 Mbps con una MTU de 1500 bytes entre dos dispositivos con un cable de 10 metros. Si tiene una cantidad X de datos que supondremos que son 100 Megabytes de datos para transportar entre el dispositivo 1 y el dispositivo 2, esto llevará más tiempo del que necesitaría con una conexión Ethernet de cobre de 30 o 100Mbps con una MTU de 1500 bytes en un medidor de 10 metros cable de cobre entre los mismos dos dispositivos. Esto se debe a que lleva más tiempo codificar y transmitir los datos en el cable y la NIC receptora será igual de lenta en recibir y decodificar las señales.
Aquí, el RTT de "datos reales", que es quizás un solo archivo de 100 MB, llevará más tiempo porque con los protocolos de nivel superior introducidos, no solo tiene que transferir los datos, sino que también los paquetes SYN, ACK y PUSH intercambiados aquí usando tiempos de bits adicionales, antes en la capa de aplicación se puede enviar un mensaje desde el dispositivo 2 al dispositivo 1 diciendo "He recibido todos los datos ahora".
Respuesta corta: no mucho
Respuesta larga:
Para llevar esto a un ejemplo de la vida real ampliando los ejemplos anteriores; Si está "haciendo ping" entre dos dispositivos que están conectados entre sí a través de varios enrutadores y / o conmutadores intermedios, el RTT es un producto de la distancia física y el tiempo que tardan las señales en viajar tan lejos y de regreso a través de todos esos dispositivos (básicamente ) Si QoS está configurado en estos dispositivos, eso también puede aumentar el retraso de extremo a extremo y complicar aún más el modelo.
No hay mucho que pueda hacer aquí aparte (en una situación puramente hipotética donde el dinero no es un objeto y la política no importa, etc.); Instale una conexión de fibra que se ejecute directamente del dispositivo 1 al dispositivo 2 cortando todos los conmutadores y enrutadores intermedios. Ese sería un escenario ideal. De manera realista, puede actualizar cualquier enlace de cobre o inalámbrico a fibra (no es que la fibra sea mucho más rápida [ i ], [ ii ]) e intente hacer que la ruta de conexión sea lo más directa posible para que los datos pasen por la menor cantidad de dispositivos intermedios y diferentes conexiones físicas El ajuste de QoS y la ingeniería de tráfico (enrutamiento basado en restricciones) también pueden ayudar a distancias más grandes con muchos saltos intermedios.
Si desea transferir datos entre puntos con lo que considera que tiene un "RTT demasiado alto", puede buscar tecnologías como TCP SACK que ya está en uso en muchos lugares, pero si lo lee, le dará un punto de partida, ya que hay otras tecnologías similares que puede considerar. Esto incluye tecnologías como los aceleradores y compresores WAN, aunque eso estaría divagando fuera del alcance de este tema. Debe considerar con la transferencia de datos a través de un enlace con un RTT alto el BDP (producto de retardo de ancho de banda, [ iii ]): cuando usa algo como TCP, esto siempre lo detendrá.
[i] El tiempo de "vuelo" sobre un medio dieléctrico de cobre es muy similar al de una guía de ondas de fibra.
[ii] Sin embargo, esto podría cambiar, es de esperar que nuevas investigaciones y tecnologías aumenten la velocidad de la luz en una fibra desde el promedio de 0.6 * c hasta cerca de 1.0 * c, http://www.orc.soton.ac.uk/ speedoflight.html
[iii] http://www.kehlet.cx/articles/99.html - Ejemplo de BDP
fuente
Lo que afecta más directamente a RTT es la velocidad de señalización. Mire la progresión de ethernet a lo largo de los eones: 10M, 100M, 1G, 10G, 40G y 100G. Cada versión siguiente (excepto 40G) es 10 veces más rápida que la anterior; el tiempo para transmitir un solo bit es 1/10 de largo. El tiempo para transmitir un cuadro completo (1500B) cae en un factor de 10.
Entonces, la respuesta a su pregunta depende de la capa de enlace. Si el cambio en el ancho de banda no tiene un cambio correspondiente en la velocidad del enlace, tendrá un efecto mínimo en RTT, porque la vigilancia del tráfico no se realiza por bit . Por ejemplo, la conexión metro-e de mi oficina es físicamente 1G, pero tiene una forma de 100M en ambos extremos. Los bits fluyen a velocidades de 1G; los marcos de ethernet se retrasarán según sea necesario para mantener el promedio (más de 1s, 10s, etc.) en o por debajo de 100M. En términos simples, una sola trama transmite a la velocidad del enlace.
Si está hablando de DSL, entonces el cambio en el ancho de banda probablemente también sea un cambio en la velocidad del enlace. Pero no siempre. La velocidad de sincronización normalmente será mayor que la velocidad del perfil. Mi línea DSL se sincroniza a 8M abajo, 1M arriba, pero el perfil lo limita a 6 / 512k. He visto que las líneas inversas se sincronizan hasta 60M pero todavía tienen un perfil de 25M.
fuente
Nadie mencionó la carga del enlace.
En enlaces vacíos, entonces no hay mucha diferencia entre 1Mb y 30Mb: asegúrese de que la codificación se puede hacer en 1/30 del tiempo, pero esto es insignificante si la distancia es el factor dominante.
Sin embargo, si el enlace de 1Mb está muy cargado (¿sobrecargado?), Verá tiempos de ping aumentados (y fluctuantes).
La misma carga de tráfico en un enlace de 30 Mb representa solo un pequeño porcentaje de su capacidad y, por lo tanto, los tiempos de ping serán más rápidos y más consistentes.
El Protocolo de medición activa bidireccional (TWAMP) define un método flexible para medir el rendimiento de IP de ida y vuelta entre dos dispositivos en una red que admite el estándar.
fuente
La verdadera respuesta es que es complicado.
La latencia se compone de múltiples componentes.
El tiempo dedicado a viajar a través del medio físico solo se puede cambiar eligiendo un medio físico diferente.
El tiempo que pasa sentado en las colas generalmente se reducirá al tener enlaces más rápidos. Así será el tiempo dedicado a serializar y des serializar datos.
Los efectos sobre el procesamiento pueden complicarse. Si el paso de procesamiento permanece igual, generalmente tomará menos tiempo a una velocidad de datos más rápida. Sin embargo, las técnicas diseñadas para extraer más ancho de banda de los enlaces existentes también pueden introducir demoras de procesamiento adicionales. Un ejemplo clásico de esto es el entrelazado DSL.
fuente