Esta es otra de esas preguntas hipotéticas. He estado tratando de averiguar si tener o no un 'segmento' más rápido de una red entre el host A y el host B se traducirá en una velocidad de flujo más rápida o una menor latencia entre ellos. Déjame mostrarte los enlaces físicos en la red entre la computadora A y la computadora B:
host A (1000Base-T NIC) -> copper 1000Base-T link -> 1G copper switch ->
[SFP module] -> a short 10G/40G/100G fibre run -> [SFP module] ->
1G copper switch -> copper 1000Base-T link -> host B (1000Base-T NIC)
En resumen, hay un enlace 1G desde el host A al primer conmutador, que tiene un módulo SFP conectado a un corto recorrido de fibra 10G / 40G / 100G (realmente no importa, solo más rápido que 1G), que se conecta a otro módulo SFP en otro conmutador de cobre 1G, que está conectado a través de cobre 1G al host B.
¿El tráfico fluye más rápido entre los dos hosts debido a que la fibra se ejecuta en el medio? ¿O la velocidad de flujo y la latencia serían las mismas si la sección entre los dos conmutadores tuviera la misma velocidad que el resto de la red?
Tendría sentido que la latencia sea menor entre el host A y el host B, pero la tasa de entrada y salida de las NIC limitaría la tasa de flujo, ¿correcto? Si es así, ¿tiene sentido conectar conmutadores y enrutadores 'centrales' junto con enlaces más rápidos?
La velocidad del flujo de datos no hace ninguna diferencia en la física del medio. Con esto quiero decir que una señal eléctrica tarda el mismo tiempo en fluir de un lado de un tramo de cobre de 100 metros al otro, sin importar si esa señal es parte de un enlace de 10Mbps o 1Gbps.
Si cambia de cobre a fibra, entonces puede notar una pequeña mejora, pero realmente debería ser solo una diferencia marginal.
Ahora, hay otros factores que pueden entrar en juego, por ejemplo, el equipo que puede hacer 10Gbps es generalmente más capaz de procesar los marcos / paquetes que el equipo diseñado para hacer 10Mbps, por lo que la latencia agregada por el equipo puede reducirse como bien. Pero esto depende completamente de las capacidades del equipo y no de la velocidad del enlace.
fuente
En este caso, pasar de 1G de extremo a extremo a un núcleo de 10G no debería cambiar significativamente nada. Solo un aumento marginal en el rendimiento provendría de la señalización más rápida (menor tiempo de bits) en el enlace 10G +. Pero en ausencia de congestión (léase: otros hosts), deberían haber podido saturar el enlace para empezar.
El tiempo que le toma a los hosts A y B señalar (entrar y salir) un paquete no cambia. El tiempo que tarda el paquete en saltar de un interruptor a otro es, en teoría, proporcionalmente más rápido. Sin embargo, a estas velocidades, la diferencia no es notable para un humano. (~ 10μs para paquete de 1500 mtu)
fuente
Dado que el rendimiento es = al tamaño de Windows / RTT, cualquier cosa que acorte el RTT aumentaría el rendimiento, es una pregunta diferente si vale la pena. Cuanto más grande es el tamaño de la ventana, más impacto tiene la disminución de RTT.
fuente
Depende.
En una red inactiva, depende de si los dispositivos de conmutación son "almacenar y reenviar" o "cortar". Si los dispositivos de conmutación se almacenan y reenvían, los enlaces más rápidos significarán una menor latencia. Sin embargo, si admiten la conmutación de corte, se introducirá una latencia adicional, ya que no es posible hacer la conmutación de un enlace entrante más lento a un enlace saliente más rápido. Sin embargo, a menos que esté jugando en el mundo comercial de alta frecuencia o similar, es probable que sea despreciable de cualquier manera.
En una red práctica, tener más capacidad en el núcleo disminuye la posibilidad de que se encuentre congestión de otros usuarios. La congestión reduce el rendimiento y la latencia. En general, es bueno si los enlaces principales son más rápidos que los enlaces de usuario final para que ningún usuario final pueda saturarlos (por lo tanto, si está ejecutando gigabit en el escritorio, probablemente debería estar ejecutando un núcleo de 10 gigabit).
fuente