Tiempos de serialización y serialización en Ethernet 40G / 10G y 100G / 25G

Recientemente participé en debates sobre los requisitos de latencia más baja para una red Leaf / Spine (o CLOS) para alojar una plataforma OpenStack.

Los arquitectos de sistemas se esfuerzan por obtener el RTT más bajo posible para sus transacciones (almacenamiento en bloque y futuros escenarios RDMA), y la afirmación es que 100G / 25G ofreció demoras de serialización muy reducidas en comparación con 40G / 10G. Todas las personas involucradas son conscientes de que hay muchos más factores en el juego de extremo a extremo (cualquiera de los cuales puede dañar o ayudar a RTT) que solo las NIC y los retrasos en la serialización de puertos. Aún así, el tema sobre los retrasos en la serialización sigue apareciendo, ya que son una cosa que es difícil de optimizar sin saltar una brecha tecnológica posiblemente muy costosa.

Un poco más simplificado (dejando de lado los esquemas de codificación), el tiempo de serialización se puede calcular como número de bits / velocidad de bits , lo que nos permite comenzar a ~ 1.2 μs para 10G (también ver wiki.geant.org ).

For a 1518 byte frame with 12'144bits,
at 10G (assuming 10*10^9 bits/s), this will give us ~1.2μs
at 25G (assuming 25*10^9 bits/s), this would be reduced to ~0.48μs 
at 40G (assuming 40*10^9 bits/s), one might expect to see ~0.3μs
at 100G (assuming 100*10^9 bits/s), one might expect to see ~0.12μs

Ahora para lo interesante. En la capa física, 40G se realiza comúnmente como 4 carriles de 10G y 100G se realiza como 4 carriles de 25G. Dependiendo de la variante QSFP + o QSFP28, esto a veces se hace con 4 pares de hebras de fibra, a veces se divide por lambdas en un solo par de fibra, donde el módulo QSFP hace algo de xWDM por sí solo. Sé que hay especificaciones para 1x 40G o 2x 50G o incluso 1x 100G carriles, pero dejémoslas a un lado por el momento.

Para estimar los retrasos de serialización en el contexto de 40G o 100G de varios carriles, uno necesita saber cómo las NIC 100G y 40G y los puertos de conmutación realmente "distribuyen los bits al (conjunto de) cable (s)", por así decirlo. ¿Qué se está haciendo aquí?

¿Es un poco como Etherchannel / LAG? La NIC / puertos de conmutación envían tramas de un "flujo" (léase: ¿el mismo resultado de hashing de cualquier algoritmo de hashing utilizado en qué ámbito de la trama) en un canal dado? En ese caso, esperaríamos retrasos en la serialización como 10G y 25G, respectivamente. Pero esencialmente, eso haría un enlace de 40G solo un LAG de 4x10G, reduciendo el flujo de flujo único a 1x10G.

¿Es algo así como un round-robin poco sabio? ¿Cada bit es round-robin distribuido en los 4 (sub) canales? En realidad, eso podría provocar retrasos en la serialización más bajos debido a la paralelización, pero plantea algunas preguntas sobre la entrega en orden.

¿Es algo así como un round-robin con marco? ¿Se envían tramas de Ethernet completas (u otros fragmentos de bits de tamaño adecuado) a través de los 4 canales, distribuidos en forma de turno redondo?

¿Es algo completamente diferente, como ...

Gracias por sus comentarios y sugerencias.

La parte que hace la división en múltiples carriles se llama Subcapa de codificación física en el estándar IEEE 802.3ba. Esta presentación de Gary Nicholl ofrece una buena visión general.

La explicación breve es que los datos se dividen en múltiples carriles en bloques de 64 bits cada uno ( codificados en el cable como 66 bits para la recuperación del reloj). Por lo tanto, tan pronto como el tamaño del paquete exceda N * 64 bits (= 32 bytes para 4 carriles), puede utilizar completamente todos los carriles. Habrá algún retraso en la codificación, pero eso probablemente sea específico de la implementación.

Este diagrama es de la presentación vinculada anteriormente:

Estás pensando demasiado.

El número de carriles utilizados realmente no importa. Ya sea que transporte 50 Gbit / s en 1, 2 o 5 carriles, el retraso de serialización es de 20 ps / bit. Por lo tanto, obtendría 5 bits cada 100 ps, ​​independientemente de los carriles utilizados. La división de datos en carriles y la recombinación se lleva a cabo en la subcapa PCS y es invisible incluso en la parte superior de la capa física. Independientemente de su situación, no importa si un PHY de 100G serializa 10 bits secuencialmente en un solo carril (10 ps cada uno, 100 ps en total) o en paralelo en 10 carriles (100 ps cada uno, 100 ps en total), a menos que usted ' re construyendo ese PHY.

Naturalmente, 100 Gbit / s tiene la mitad del retraso de 50 Gbit / sy así sucesivamente, por lo que cuanto más rápido se serialice (en la parte superior de la capa física), más rápido se transmitirá una trama.

Si está interesado en la serialización interna en la interfaz, deberá mirar la variante MII que se está utilizando para la clase de velocidad. Sin embargo, esta serialización se lleva a cabo sobre la marcha o en paralelo con la serialización MDI real: lleva una cantidad de tiempo mínima, pero eso depende del hardware real y probablemente sea imposible de predecir (algo a lo largo de 2-5 ps Sé mi suposición de 100 Gbit / s). Realmente no me preocuparía por esto, ya que hay factores mucho más grandes involucrados. 10 ps es el orden de latencia de transmisión que obtendría de un cable adicional de 2 milímetros (!).

Usar cuatro carriles de 10 Gbit / s cada uno para 40 Gbit / s NO es lo mismo que agregar cuatro enlaces de 10 Gbit / s. Un enlace de 40 Gbit / s, independientemente de la cantidad de carriles, puede transportar una sola transmisión de 40 Gbit / s que los enlaces LAGged de 10 Gbit / s no pueden. Además, el retraso de serialización de 40G es solo 1/4 del de 10G.