Problèmes de proportionnalité énergétique d’Internet : quand le plus est l’ennemi du bien (JCSA24)

[@flexable9256]

J'ai un très gros problème avec cette conférence. Ce qui est présenté au début me laisse perplexe. Je travaille dans les réseaux, j'ai designé / migré / monitoré des réseaux opérateurs, maintenant je travaille pour un constructeur et ma réalité du terrain ne correspond pas avec les propos tenus. Si je regarde un routeur 100G MPLS chez nous, petit format (1U, 12x100G + 24x10G) car c'est notre marché, il possède une double alimentation de 650W chacune. Sa consommation au maximum (tous les ports connectés, 100% de charge de trafic) c'est 563W. A 10% de charge de trafic, tout le reste étant identique, c'est 176W. Si je regarde un ancien châssis (plus commercialisé depuis des années), 8 slots, avec des modules 100G (36 ports par module), totalement rempli et redondance maximale de tous les composants, la consommation du châssis à 50% de charge c'était ~7400W, à 100% de charge ~9300W. Ca fait dans les 25% d'écart tout de même, entre 50% de charge et 100%. Si on reprend le discours et le modèle présenté vers 8:00 avec le P0 et P1, il y a un abime de différence. Ce qui est vrai, c'est qu'un châssis présente une consommation en propre qui est significative, le gain se fait plus vous le remplissez en modules et plus la charge devient importante. Souvent, en phase initiale, le châssis aura quasi toute la redondance des composants installée, donc une consommation en propre quasi maximale, pour un nombre de modules qui sera faible. Mais ce nombre de modules est appelé à croître pour atteindre le maximum à un moment. Là, ça dépend de l'augmentation du trafic localement, et il y a des cas où ça ne bougera pas, et d'autres où ça ira très vite. Ce que je veux dire, c'est que le diagramme vers 8:00 est vrai par endroit, à un instant t, mais ce n'est absolument pas une généralité. Effectivement, s'il n'y a qu'un seul exemple concret pour valider ces chiffres, avec l'opérateur suisse qui n'a que 2% de charge de trafic, alors oui, vu que l'exemple montrait une variation de trafic entre 1% et 3% en pic, ce diagramme devient vrai. Mais c'est du cherry-picking d'un cas isolé non représentatif. Et attention à ces statistiques : il faut voir la fréquence de sampling. Ce sont des valeurs moyennes lissées qui peuvent cacher des pics (burst) très importants, mais très bref. Pour donner un exemple, mais qui sort du cadre des Telcos, sur des flux vidéos SD, dont vous connaissez le bitrate (et en SD c'est faible), le fait d'en agréger 10 sur un lien 1Gbps sur un LAN est en théorie un non-problème. La somme ne vaut même pas 50Mbps. Pourtant il y a des bursts qui saturent le lien et engendrent de la perte de paquets. Mais les graphs de monitoring "à la minute" ne montrent une utilisation que d'une poignée de pourcents. J'ai noté le commentaire du représentant de Renater qui parle de liens à 17% où il y a déjà des impacts utilisateurs... Ces informations de consommation électrique ne sont pas forcément simples à trouver publiquement (pas là où je travaille, c'est publique, mais en cherchant rapidement chez d'autres on ne trouve que les max), et généralement les constructeurs se contentent de communiquer sur le maximum du système car c'est sur cette base que les électriciens vont dimensionner les besoins - quel est l'appel de puissance max possible. Ensuite, je tiens à souligner que l'exemple pris à 11:00 concerne un Cisco Nexus 9300 (comme indiqué). Ce n'est pas un routeur de Telco, c'est un équipement de DC. Si on va sur la datasheet publique de cette famille d'équipements, on a les valeurs de consommation électrique "Typique" vs "Maximale" (vous en parlez plus tard). Ca donne, selon les modèles, 228W/508W, 210W/537W, 374.5W/694W, 542W/948W (ça, vous n'en parlez pas). Un bel exemple de contre-exemple du propos tenu. Il y a 3mn d'écart dans la présentation entre ce fameux graphique avec un P0 et un P1 très proche et maximal qui sert de sujet, et ce premier exemple concret d'un équipement sur lequel des tests sont faits et qui affiche un ratio de 2:1 en consommation en fonction de la charge. Oui, "typical" n'est pas très précis, mais ça implique en fait une charge de trafic qui n'est pas 100% (et généralement pour une température de 25°c). Et, dans l'absolu, peu importe : ces ratios du simple au double entre le typical et le max sont un contre-exemple flagrant du propos du début. La consommation instantanée (la puissance en fait) d'un équipement, PSU par PSU, est généralement disponible (vous avez cité Juniper : show chassis power). A 27:20 vous parlez de réduire la vitesse d'un lien (exemple passer un 100G à 10G). Ce n'est pas aussi trivial que ça. Un 100G, ça peut être plusieurs choses selon le type de transceiver. Le plus classique, c'est en fait un 4x25G. Pour passer à 10G, il faut changer le débit série (25G -> 10G), et passer de 4 lignes à 1. Ca implique une re-négociation entre équipements, une capacité de changement dynamique de toute la chaîne (pas de reboot sur un maillon de la chaîne), typiquement un changement de la FEC (spécifique au 25G, indisponible sur le 10G), et cela a un impact sur l'IGP qui va devoir engendrer des recalculs de topologie sur l'intégralité du réseau (local, au sein du même AS) : ce n'est pas gratuit en énergie. Comme vous avez aussi dit que le gain entre 100G et 10G est très faible... A la suite, vous parlez du besoin de ne pas sur-dimensionner les équipements électriquement, notamment sur le nombre de PSUs installés. Je ne connais pas tous les opérateurs du monde, mais les gros routeurs opérateurs proposent des redondances entre N+1 et N+N. Côté PSU, ce N+N n'est pas là pour gérer N défaillances de PSU, mais plutôt pour offrir un 1+1 sur la source électrique. Lorsqu'il n'y a pas de double adduction, tout le monde se contente de N+1. Sur ce point, les gains sont à chercher sur l'efficacité des alims (on est déjà, normalement, en 90+) et la baisse de consommation globale du système. Ca n'invalide pas un besoin et une recherche sur comment continuer à réduire la consommation des équipements, mais je reste surpris sur l'écart entre la réalité et la description faite. J'ai du mal à croire que l'enjeu soit aussi important entre l'infrastructure opérateur (de transport) et les besoins en énergie des CPU, NPU et GPU dans les DC. Un ASIC, c'est déjà pas mal optimisé par nature (par rapport à ce que fournirait une CPU ou un FPGA).

[@SandraTaylor-x3s]

Super contenu, comme toujours! Juste une petite question hors sujet: J'ai un portefeuille SafePal avec des USDT et j'ai la phrase de récupération. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). Quelle est la meilleure façon de les envoyer vers Binance?