Latencia de red: 100Mbit vs. 1Gbit

11

Tengo un servidor web con una conexión actual de 100Mbit y mi proveedor ofrece una actualización a 1Gbit. Entiendo que esto se refiere al rendimiento, pero cuanto más grandes son los paquetes, más rápido también se pueden transmitir, por lo que esperaría una ligera disminución en el tiempo de respuesta (por ejemplo, ping). ¿Alguien alguna vez comparó esto?

Ejemplo (servidor de 100mbit a 100mbit) con carga de 30 bytes:

> ping server -i0.05 -c200 -s30
[...]
200 packets transmitted, 200 received, 0% packet loss, time 9948ms
rtt min/avg/max/mdev = 0.093/0.164/0.960/0.093 ms

Ejemplo (servidor de 100mbit a 100mbit) con una carga de 300 bytes (que está por debajo de MTU):

> ping server -i0.05 -c200 -s300
[...]
200 packets transmitted, 200 received, 0% packet loss, time 10037ms
rtt min/avg/max/mdev = 0.235/0.395/0.841/0.078 ms

Entonces de 30 a 300 el promedio. la latencia aumenta de 0.164 a 0.395: esperaría que este sea un aumento más lento para una conexión de 1 gibt a 1 gbit. Incluso esperaría que 100mbit a 1gbit sea más rápido, si la conexión es a través de un conmutador que primero espera hasta que reciba el paquete completo.

Actualización: ¡ Lea los comentarios a las respuestas cuidadosamente! La conexión no está saturada, y no creo que este aumento de velocidad sea importante para los humanos para una solicitud, pero se trata de muchas solicitudes que se suman (Redis, Base de datos, etc.).

Respecto a la respuesta de @LatinSuD :

> ping server -i0.05 -c200 -s1400
200 packets transmitted, 200 received, 0% packet loss, time 9958ms
rtt min/avg/max/mdev = 0.662/0.866/1.557/0.110 ms
Andreas Richter
fuente
También hay una codificación diferente (¿10b / 12b?) Con nuevas tarjetas y cables gbit ethernet, por lo que podría tener un rendimiento 25% más en la parte superior de 10x (cuando está saturado) frente a 100Mbit tal vez?
huseyin tugrul buyukisik

Respuestas:

15

La única forma en que la latencia se reduciría notablemente es si el enlace actual de 100Mbit está saturado. Si no está saturado, es probable que no note ningún cambio.

Además, su suposición de que el enlace de 1 Gbit podrá admitir paquetes más grandes es incorrecta. El tamaño máximo de paquete está determinado por la MTU de los diversos dispositivos a lo largo de la ruta que toma el paquete, comenzando con la NIC en su servidor, hasta la MTU de la computadora de su cliente. En aplicaciones LAN internas (cuando tiene control sobre todos los dispositivos a lo largo de la ruta), a veces es posible aumentar la MTU, pero en esta situación, está atascado con la MTU predeterminada de 1500. Si envía paquetes más grandes que eso, terminarán fragmentándose, disminuyendo así el rendimiento.

EEAA
fuente
2
"Apreciablemente" es la palabra clave aquí. Acabo de revisar dos servidores con hardware idéntico y baja carga de red, pero con diferentes velocidades de Ethernet. El tiempo promedio de ping (local, con la fuente de ping en la misma subred) se redujo de 0.21 milisegundos a 0.17 milisegundos. Al hacer ping a los mismos servidores desde casa, cada uno tenía un tiempo de 53 milisegundos. Hay demasiados factores que escapan al control de su proveedor para que sea una actualización que valga la pena.
Mike Renfro
1
+1 Técnicamente hay una diferencia, sin embargo, es completamente inapreciable a menos que la aplicación en particular sea increíblemente sensible a la latencia.
Chris S
Gracias por la prueba! De 0.21 a 0.17 es una mejora del 20%, lo cual es genial. No me preocupa el ping desde casa (50 ms) pero el tiempo que la solicitud permanece en el proveedor. Ajustamos al máximo todo el procesamiento (CPU) y el no IO de la unidad (RAM / caché / etc.), por lo que ahora me pregunto cuánto agrega la velocidad de red entre los servidores a la latencia total como total. Por ejemplo, hacemos ~ 20 solicitudes Redis para una solicitud de servidor web. @MikeRenfro: ¿puedes hacer la misma prueba con un mayor tamaño de carga? El ping normal es 30byte, promedio. Redis alrededor de 250. Esperaría que la diferencia crezca.
Andreas Richter
2
@Andreas; Creo que te perdiste totalmente el punto de esos comentarios. Esa es una mejora de 40 nanosegundos. Una cantidad que es completamente imperceptible para los seres humanos . Y ese no es un número acumulativo, no es que cada solicitud tarde 40 nanosegundos más; es solo que el primero será mucho más rápido, por lo que el segundo se alineará justo detrás de cualquier manera.
Chris S
1
@ChrisS: la pregunta no era sobre la perceptibilidad : era una pregunta si alguien lo había probado y Mike lo hizo. Tampoco son 40 nanosegundos, son microsegundos , por lo que te estás perdiendo el punto por factor 1000 ... felicitaciones. Créame, sé lo que estoy haciendo ... 20% sería suficiente para justificar los costos adicionales.
Andreas Richter
12

SÍ gbit tiene una latencia más baja, ya que:

  • la misma cantidad de bytes se puede transferir en un tiempo más rápido

PERO la mejora solo es apreciable si los paquetes tienen un cierto tamaño:

  • Paquete de 56 bytes => prácticamente sin transferencia más rápida
  • Paquete de 1000 bytes => transferencia 20% más rápida
  • Paquete (s) de 20000 bytes => Transferencia 80% más rápida

Entonces, si tiene una aplicación que es muy sensible a la latencia (4 ms frente a 0,8 ms, ida y vuelta por 20 kb) y requiere que se transfieran paquetes más grandes, entonces cambiar de 100mbit a gbit puede proporcionarle una reducción de latencia, aunque use mucho menos que los 100mbit / s en promedio (= el enlace no está saturado permanentemente).

Servidor (100mbit) -> Switch (gbit) -> Servidor (100mbit):

size: 56 :: rtt min/avg/max/mdev = 0.124/0.176/0.627/0.052 ms
size: 100 :: rtt min/avg/max/mdev = 0.131/0.380/1.165/0.073 ms
size: 300 :: rtt min/avg/max/mdev = 0.311/0.463/2.387/0.115 ms
size: 800 :: rtt min/avg/max/mdev = 0.511/0.665/1.012/0.055 ms
size: 1000 :: rtt min/avg/max/mdev = 0.560/0.747/1.393/0.058 ms
size: 1200 :: rtt min/avg/max/mdev = 0.640/0.830/2.478/0.104 ms
size: 1492 :: rtt min/avg/max/mdev = 0.717/0.782/1.514/0.055 ms
size: 1800 :: rtt min/avg/max/mdev = 0.831/0.953/1.363/0.055 ms
size: 5000 :: rtt min/avg/max/mdev = 1.352/1.458/2.269/0.073 ms
size: 20000 :: rtt min/avg/max/mdev = 3.856/3.974/5.058/0.123 ms

Servidor (gbit) -> Switch (gbit) -> Servidor (gbit):

size: 56 :: rtt min/avg/max/mdev = 0.073/0.144/0.267/0.038 ms
size: 100 :: rtt min/avg/max/mdev = 0.129/0.501/0.630/0.074 ms
size: 300 :: rtt min/avg/max/mdev = 0.185/0.514/0.650/0.072 ms
size: 800 :: rtt min/avg/max/mdev = 0.201/0.583/0.792/0.079 ms
size: 1000 :: rtt min/avg/max/mdev = 0.204/0.609/0.748/0.078 ms
size: 1200 :: rtt min/avg/max/mdev = 0.220/0.621/0.746/0.080 ms
size: 1492 :: rtt min/avg/max/mdev = 0.256/0.343/0.487/0.043 ms
size: 1800 :: rtt min/avg/max/mdev = 0.311/0.672/0.815/0.079 ms
size: 5000 :: rtt min/avg/max/mdev = 0.347/0.556/0.803/0.048 ms
size: 20000 :: rtt min/avg/max/mdev = 0.620/0.813/1.222/0.122 ms

= en promedio en varios servidores 80% de reducción de latencia para ping de 20 kb

(Si solo uno de los enlaces es gbit, aún tendrá una reducción de latencia del 5% para ping de 20 kb).

Andreas Richter
fuente
1
Con la mayoría de los equipos de red almacenados y reenviados, un paquete / enrutador debe recibir completamente un paquete antes de pasarlo. Las conexiones más rápidas reducen este tiempo, lo que también reduce la latencia (siempre que la conexión no obtenga la velocidad de varios enlaces paralelos).
Brian
1
Debido a la explicación, esta respuesta es, con mucho, la mejor de la página. Los demás parecen querer explicar este hecho asumiendo un caso especial: el rendimiento de la red a través de una gran distancia / muchos conmutadores. Es importante tenerlo en cuenta, especialmente teniendo en cuenta la preocupación del OP (servidor web), pero esta respuesta también muestra cuánta diferencia puede hacer la velocidad del interruptor en un solo salto.
Tyler
3

Creo que tiene una idea errónea fundamental sobre la latencia del ancho de banda y la "velocidad". La velocidad es una función del ancho de banda y la latencia. Por ejemplo, considere un envío de datos en DVD enviados en todo el país que demore 3 días en llegar. Compare eso con el envío de datos a través de Internet. Internet tiene una conexión de latencia mucho más baja, pero para que coincida con la "velocidad" de la conexión al envío, debería haber recibido a 9.6MB por segundo ( ejemplo de referencia de esta fuente ).

En su caso, la actualización a un mayor ancho de banda le permitiría atender a más usuarios concurrentes, pero no mejoraría la latencia de ningún usuario individual.

Jim B
fuente
Eso es incorrecto: simplemente compare el ping con una carga útil diferente que está por debajo de la MTU actual: servidor de ping -i0.05 -c200 -s30 versus servidor de ping -i0.05 -c200 -s300 ... O hablando en su ejemplo: el un camión con 1 millón de DVD conduciría más lento, porque es más pesado que el que tiene 1 DVD.
Andreas Richter
2
@andreas el tiempo de ping no es toda la historia, así que tomemos como argumento que los paquetes inferiores a la MTU llegan más rápido que los paquetes a la MTU completa. la diferencia es que no tiene todos los datos que tiene el paquete 1 a mtu completo en la misma cantidad de tiempo que tardan en llegar los 2 paquetes. La latencia es el tiempo que tardan en llegar todos los datos. para volver a la analogía del camión, incluso si se necesita un camión con 1 Cd para llegar en la mitad del tiempo que el camión que transporta 500 CD, todavía se necesita ese camión 500 viajes para entregar los datos (750 días frente a 3).
Jim B
@ JimB: sí, como mencioné, mi pregunta no era sobre el tamaño de la carga, sino sobre la velocidad: el camión completo necesita 10 horas para ser escaneado por la aduana, el pequeño solo 1 hora. 100mbit / s también significa que un paquete de 100 bits necesita un mínimo teórico de 0,000954 ms y un paquete de 1000 bits un mínimo teórico de 0,00954 ms. Por supuesto, tiempo de procesamiento / etc. en la tarjeta de red / conmutador / etc. hacer una porción más alta de toda la latencia, pero también esperaría que estos sean más rápidos en un interruptor de 1 gbit, etc. Por favor, vea el comentario de @MikeRenfro, en realidad lo probó y llegó a un aumento del 20%.
Andreas Richter
@andreas - 20% en la misma subred que es irrelevante para su pregunta
Jim B
1
@andreas El 20% de un ping por debajo de milisegundos sigue siendo un ping por debajo de milisegundos. Incluso el 150% de un ping de menos de milisegundos, como en sus pruebas, no va a importar en el mundo real. ¿Realmente tiene una aplicación donde importa si sus datos llegaron allí en 0.0003 segundos en lugar de 0.0002 segundos ?
Shane Madden
2

Estás mirando el mundo a través de un agujero de alfiler. Una prueba válida de las diferencias de latencia a diferentes velocidades sería entre dos NIC idénticas conectadas con un cable de conexión cruzada. Establezca las velocidades de emparejamiento de NIC de 10mb, 100mb y 1000mb. Esto mostrará que prácticamente no hay diferencia en la latencia a las diferentes velocidades. Todos los paquetes viajan a la misma velocidad de cable, independientemente del ancho de banda máximo utilizado. Una vez que agrega interruptores con almacenar y reenviar el almacenamiento en caché, todo cambia. La prueba de latencia a través de un conmutador debe realizarse con solo dos conexiones al conmutador. Cualquier otro tráfico puede afectar la latencia de su prueba. Incluso entonces, el conmutador puede transferir registros, ajustar los contadores de tipo de paquete, actualizar el reloj interno, etc. Todo puede afectar la latencia.

Sí, cambiar de 100mb a 1gb podría ser más rápido (menor latencia) debido a cambios de hardware, diferentes NIC, diferentes interruptores, diferentes controladores. He visto cambios más grandes en la latencia de ping de las diferencias de controladores que cualquier otro cambio; ancho de banda, conmutadores, NIC de descarga, etc.

El cambio sería el próximo cambio más importante con un corte significativamente más rápido que almacenar y reenviar para pruebas de transmisión única. Sin embargo, un interruptor de almacenamiento y avance bien diseñado puede adelantar al interruptor de corte en el rendimiento general bajo una carga alta. En los primeros días de gigabit, he visto conmutadores de plano posterior de alto rendimiento de 10 MB con una latencia más baja que los conmutadores gigabit baratos.

Las pruebas de ping son prácticamente irrelevantes para el análisis de rendimiento cuando se utiliza Internet. Son pruebas rápidas para tener una idea aproximada de lo que sucede en el transporte en el momento de la prueba. Las pruebas de rendimiento de producción son mucho más complicadas que un simple ping. Los interruptores de alto rendimiento son computadoras y bajo alta carga se comportan de manera diferente: cambio en la latencia.

Tener una NIC más lenta, o una NIC configurada a una velocidad más lenta, en realidad podría ayudar a un servidor con ráfagas concurrentes al limitar la entrada al servidor utilizando la caché de conmutadores. Una sola retransmisión puede negar cualquier disminución en la latencia. Por lo general, los niveles de tráfico de carga media a alta son importantes, no pruebas de ping individuales. por ejemplo, el viejo y lento Sun Ultrasparc (mayor latencia para un solo ping) supera al nuevo escritorio gigabit barato que se utiliza como servidor de desarrollo cuando tiene una carga de ancho de banda inferior al 70%. El escritorio tiene una NIC gb más rápida, una conexión gb-gb más rápida, una memoria más rápida, más memoria, un disco más rápido y un procesador más rápido, pero no funciona tan bien como el hardware / software de clase de servidor sintonizado. Esto no quiere decir que un servidor sintonizado actual que ejecuta gb-gb no sea más rápido que el hardware antiguo, incluso puede manejar cargas de mayor rendimiento. Simplemente hay más complejidad en la cuestión de "

Averigüe si su proveedor está utilizando diferentes conmutadores para las conexiones de 100 mb frente a 1 gb. Si usan el mismo panel posterior del interruptor, solo pagaría el aumento si los niveles de tráfico superaran el ancho de banda más bajo. De lo contrario, es posible que en poco tiempo muchos otros usuarios se cambien al gigabit y los pocos usuarios que quedan en el antiguo conmutador ahora tengan un mayor rendimiento: menor latencia, durante altas cargas en el conmutador (carga general del conmutador, no solo a sus servidores )

Ejemplo de manzanas y naranjas: el ISP local proporcionó un nuevo conmutador para servicios integrados, DSL y teléfono. Inicialmente, los usuarios vieron un aumento en el rendimiento. El sistema estaba sobrevendido. Ahora los usuarios que permanecen en el conmutador anterior tienen un rendimiento consistente más alto. Durante la noche, los usuarios del nuevo sistema son más rápidos. Por la noche, bajo una gran carga, los antiguos clientes de conmutadores superan claramente al nuevo sistema sobrecargado.

Una latencia más baja no siempre se correlaciona con una entrega más rápida. Usted menciona MySQl en las 20 solicitudes para publicar una sola página. Ese tráfico no debe estar en la misma NIC que la página solicita. Mover todo el tráfico interno a una red interna reducirá las colisiones y el recuento total de paquetes en la NIC saliente y proporcionará mayores ganancias que la ganancia de latencia de 0.04 ms de un solo paquete. Reduzca el número de solicitudes por página para reducir la latencia de carga de la página. Comprima las páginas, html, css, javascript, imágenes para disminuir los tiempos de carga de la página. Estos tres cambios darán mayores ganancias generales continuas que pagar por el ancho de banda que no se usa para obtener una reducción de latencia de 0.04 ms. El ping debe ejecutarse las 24 horas y promediarse para ver el verdadero cambio de latencia. Los conmutadores inteligentes ahora hacen una aceleración adaptativa de tipo RTSP con pequeños aumentos iniciales de ancho de banda y grandes transferencias aceleradas. Dependiendo de los tamaños de sus páginas (gráficos, html / css / javascript grandes), puede ver latencias de conexión iniciales / ancho de banda mucho más bajo / más alto que una página grande o transferencias de página completa. Si parte de su página está transmitiendo, puede ver un rendimiento drásticamente diferente entre la página y la transmisión.

joe
fuente
Gracias por todos los excelentes aportes: 1.) Es el mismo interruptor, 2.) Una segunda NIC para sonidos internos / externos razonable y que vale la pena probar, aunque, por ejemplo, MySQL / etc. son todos bidireccionales, por lo que las colisiones "solo" se reducirían a la mitad, 3.) Una prueba del mundo real es preferible a solo Nic-Nic, Mike lo hizo con una subred y obtuvo lo que esperaba. hardware: "56 bytes = 19% de mejora, 200 bytes = 27%, 1000 bytes = 59%. Por lo tanto, cuanto más grande sea el paquete, más importa. Y Gigabit aumentó solo de 0,17 ms (56 bytes) a 0,23 ms (1000 bytes) ) => 35%, mientras que 100 Mbit aumentaron de 0.21 a 0.56 => 166% ".
Andreas Richter
1

Supongamos paquetes de 300 bytes (si lo usa, -s 300en realidad sería más grande debido a los encabezados).

300 bytes = 2400 bits
2400 bits / 100Mbit/sec = 0.024ms

0.024 ms es aproximadamente el tiempo real requerido para enviar la trama (sin contar el tiempo de acceso medio ni los encabezados).

En una secuencia de ping-pong, tomaría el doble de tiempo (0.048 ms), más el tiempo para que el sistema operativo procese la consulta.

Eso significa para mí que su latencia es causada por un 90% de varios factores generales. No estoy seguro si verá mucha diferencia con Gb. Probablemente, una diferencia de menos de 1 ms no se notará en un servidor web.

De todos modos, ¿podrías probar con un paquete realmente grande como 1400 byte?

LatinSuD
fuente
Alguien ya ejecutó los números para un servidor en particular y la diferencia volvió a 40 nanosegundos. Su estimación aproximada es un factor 25 veces mayor.
Chris S
@LatinSuD: gracias por el enfoque constructivo y no culpar a que no sé lo que estoy haciendo. Publicaré los resultados en la pregunta real ya que puedo formatear allí. Pero por cierto. También esperaría que la sobrecarga del 90% tenga un aumento de velocidad , ya que los procesadores en las tarjetas de red, etc., también son más rápidos para GBit (con suerte). @ChrisS: microsegundos y no entiendo lo que quieres decir con los 25.
Andreas Richter
Mis disculpas por mezclar micro y nano; en cualquier caso es imperceptible. LatinSuD estimó una diferencia de 1 milisegundo completo, que es 25 veces más que los 40 microsegundos encontrados por Mike.
Chris S
@ChrisS: no te preocupes. El 0,04 ms fue para un ping de 38 bytes, si nuestro paquete servidor-servidor promedio es de alrededor de 300 bytes, la diferencia podría ser 0,4 ms. Si ahora hacemos 20 solicitudes para una solicitud de servidor web (Redis, MySQL, etc.), esto conduciría a un aumento de velocidad de 8 ms, que sería un aumento de velocidad del 10% para las solicitudes web actuales y justificaría totalmente los costos adicionales. Simplemente no tengo los recursos aquí para ejecutar las pruebas por mí mismo, pero créanme, que incluso si no es perceptible por los humanos, aún puede ser relevante. Como la electricidad o dios.
Andreas Richter
1
@Andreas, dudo mucho que vaya a escalar así; tanto un paquete 10 veces más grande tiene 10 veces menos latencia como 20 veces más paquetes 20 veces más rápido. Si funciona, es una reducción del 10% en la sobrecarga de la red, aún debe tener en cuenta el tiempo dedicado a la aplicación, que probablemente sea de uno a varios órdenes de magnitud más que el componente de latencia de la red. Espero que te funcione bien en cualquier caso.
Chris S
1

Esto depende del tipo de interruptor al que se está conectando. En algunos proveedores (como Crisco ... me refiero a Cisco), los paquetes ICMP regresarán a la CPU ( mordaza ).

Puede encontrar una mejor prueba sería realizar una prueba de host a host utilizando un enlace de 100Mbps y 1Gbps (es decir, no una prueba de host a switch o de host a enrutador).

Al final del día, la latencia se reducirá a la velocidad de reenvío en el conmutador y los detalles de la arquitectura del conmutador (donde se colocan los ASIC en el tablero, cómo se maneja el bloqueo entre las tarjetas de línea, etc.). Buena suerte con tus pruebas.

Sean
fuente
Gracias, solo me refiero a las pruebas Host-Switch-Host y no entiendo todo el cambio interno. Simplemente me encantaría ver, si alguien alguna vez comparó: Host- (100mbit) -Switch- (100mbit) -Host, Host- (100mbit) -Switch- (1gbit) -Host y Host- (1gbit) -Switch- (1gbit ) -Host latencia para diferentes tamaños de paquetes. Si nadie lo hizo, lo haré y publicaré la respuesta aquí.
Andreas Richter
1
Solía ​​revender equipos de cambio. Baste decir que sus hallazgos me sugieren que está conectado a un conmutador Cisco. Hay otras alternativas que proporcionan latencias más bajas. Como señaló correctamente, más ancho de banda no se traduce en latencias más bajas (Comcast es el principal culpable de hacer que las personas sean tontas a este respecto). Dado que está en un entorno alojado, probablemente esté atrapado con su hardware (y dado que en un entorno hospedado, los pocos microsec adicionales no son terriblemente cruciales). Muéstrame millones de pps en estado estacionario y me interesaré en proporcionar más detalles. :)
Sean