Contrôle de congestion pour l'Ethernet IA : une correction utile en simulation, mais encore moins performante dans un cas

L'entraînement d'un grand modèle d'IA envoie d'énormes rafales de données entre des milliers de puces à la fois. Quand le réseau se bloque, le transfert le plus lent fixe la vitesse de toute la tâche. Les fabricants de réseaux conçoivent de nouveaux contrôles de congestion pour cela. Nous avons travaillé dans un simulateur public du design Ultra Ethernet (uet-htsim), avec la méthode publiée MNSCC comme point de départ. Nous n'avons aucun lien avec Cisco ni aucun autre fabricant.

Une modification d'une seule ligne a réduit le temps de transfert typique de 3 à 37 % dans cinq scénarios de trafic simulés, mais a légèrement dégradé les résultats en incast. Il s'agit d'un résultat de simulation dont la nouveauté n'a pas été vérifiée.

Avant de mesurer, nous avons noté les hypothèses et les critères de réussite. Notre première idée - adapter à quel point le contrôleur lisse son signal de délai - a échoué dans deux conceptions. Aucune n'a fonctionné sur le motif incast, où de nombreux émetteurs envoient leurs données au même récepteur. Nous l'avons consigné comme un résultat négatif.

Au troisième tour, nous avons cherché pourquoi une conception perdait parfois lourdement sur une seule graine aléatoire. Dans un cas, le flux le plus lent avait un délai sous la cible, mais 72 % de ses paquets étaient marqués comme congestionnés. Le seuil de marquage (40 Ko de file) se situe sous la file cible (environ 100 Ko), donc une marque dit seulement que la file dépasse 40 Ko. Le contrôleur réduisait alors sa fenêtre d'environ 36 % à chaque aller-retour. Cela explique ce cas à partir des traces. Ce n'est pas une preuve pour tous les cas.

La correction, gelée avant le test sur des nouvelles graines aléatoires : ne réduire la fenêtre que si le délai médian est aussi à la cible ou au-dessus. Rien d'autre n'a changé.

Source : REPORT3.md, validation sur des graines aléatoires non utilisées dans la conception. Les étiquettes sont les noms de scénarios propres au simulateur (ele = scénarios de trafic croisé à 16 et 8 chemins, failed8 = avec des liens en panne) ; leurs définitions complètes sont dans le rapport d'origine. 20 graines aléatoires appariées au total : 5, 5, 3, 3 et 2 par scénario. Aucun essai n'a donné un moins bon résultat dans ces scénarios de trafic croisé. Cela ne vaut que pour ces 20 graines aléatoires.

Incast (3 graines aléatoires)

Temps de transfert moyen 2530 contre 2455 pour la référence adaptative (+3,1 %) en placement local, et 2507 contre 2450 (+2,3 %) en placement dispersé. Temps de transfert maximal à peu près égal (+0,3 % et +0,4 %). La méthode NSCC simple reste la meilleure sur la moyenne incast (2382 et 2444). Notre critère gelé était plus ou moins 2 %, donc c'est un ÉCHEC.

Pire résultat pour une graine aléatoire sur incast

+11,8 %, contre +18 % avant la correction.

• Simulation uniquement : un fat-tree idéalisé de 128 ou 1024 nœuds et 2 à 5 graines aléatoires par scénario.
• MNSCC est une méthode publiée, pas la nôtre. Que notre variante soit nouvelle n'est pas vérifié. Les idées publiées les plus proches que nous avons trouvées sont APSCC et STrack.
• La perte restante sur incast peut venir de l'ampleur des réductions. C'est une hypothèse issue des traces.
• Pas une percée. Sans matériel ni implication d'un fabricant.