Control de congestión para Ethernet de IA: una corrección que ayuda en simulación y un caso en el que sigue rindiendo peor

Entrenar un modelo grande de IA envía enormes ráfagas de datos entre miles de chips a la vez. Cuando la red se atasca, la transferencia más lenta fija la velocidad de todo el trabajo. Los fabricantes de red están diseñando nuevos controles de congestión para esto. Trabajamos en un simulador público del diseño Ultra Ethernet (uet-htsim), con el método publicado MNSCC como punto de partida. No tenemos ninguna relación con Cisco ni con ningún otro fabricante.

Un cambio de una sola línea redujo el tiempo de finalización típico entre un 3 y un 37 % en cinco escenarios de tráfico simulados, pero empeoró ligeramente los resultados en incast. Es un resultado de simulación cuya novedad no se ha comprobado.

Antes de medir, anotamos las hipótesis y los criterios de éxito. Nuestra primera idea - adaptar cuánto suaviza el controlador su señal de retardo - falló en dos diseños. Ninguno funcionó en el patrón incast, donde muchos emisores envían datos a un mismo receptor. Lo registramos como resultado negativo.

En la tercera ronda examinamos por qué un diseño a veces perdía mucho en una sola semilla. En un caso, el flujo más lento tenía retardo bajo el objetivo, pero el 72 % de sus paquetes estaban marcados como congestionados. El umbral de marcado (40 KB de cola) está por debajo de la cola objetivo (unos 100 KB), así que una marca solo dice que la cola supera 40 KB. El controlador reducía entonces su ventana un 36 % en cada ida y vuelta. Eso explica este caso a partir de las trazas. No es una prueba para todos los casos.

La corrección, congelada antes de probar en semillas nuevas: reducir la ventana solo si el retardo mediano también está en el objetivo o por encima. Nada más cambió.

Fuente: REPORT3.md, validación en semillas no usadas en el diseño. Las etiquetas son los nombres de escenarios propios del simulador (ele = escenarios de tráfico cruzado a 16 y 8 rutas, failed8 = con enlaces fallidos); sus definiciones completas están en el informe original. 20 semillas pareadas en total: 5, 5, 3, 3 y 2 por escenario. Ningún ensayo obtuvo peores resultados en estos escenarios de tráfico cruzado. Eso vale solo para estas 20 semillas.

Incast (3 semillas)

Tiempo medio de finalización 2530 frente a 2455 de la línea base adaptativa (+3,1 %) con colocación local, y 2507 frente a 2450 (+2,3 %) con colocación dispersa. Tiempo máximo de finalización casi igual (+0,3 % y +0,4 %). El método NSCC simple sigue siendo el mejor en la media de incast (2382 y 2444). Nuestro criterio congelado era más o menos 2 %, así que esto FRACASÓ.

Peor semilla individual en incast

+11,8 %, frente a +18 % antes de la corrección.

• Solo simulación: un fat-tree idealizado con 128 o 1024 nodos y de 2 a 5 semillas por escenario.
• MNSCC es un método publicado, no nuestro. Si nuestra variante es nueva está sin verificar. Las ideas publicadas más cercanas que encontramos son APSCC y STrack.
• La pérdida restante en incast puede venir del tamaño de las reducciones. Es una hipótesis a partir de las trazas.
• No es un avance decisivo. Sin pruebas en hardware ni participación de ningún fabricante.