Vous achetez deux CPU « identiques » pour deux serveurs « identiques ». Même modèle. Même BIOS. Même refroidissement. Une machine travaille
sans encombre sous charge ; l’autre chauffe davantage, booste moins et commence à générer des erreurs machine-check corrigées comme pour attirer l’attention.
En production, ce n’est pas anecdotique. C’est un rapport d’incident en attente.
La vérité gênante : une grande partie de votre parc matériel résulte d’un processus de tri. Une même conception physique de die devient
plusieurs niveaux de prix via le binning. Ce n’est pas une conspiration. C’est la réalité de la fabrication plus des incitations commerciales,
emballées dans assez de marketing pour donner l’impression d’un destin.
Le binning en un paragraphe
Le binning est la pratique qui consiste à tester le silicium fabriqué (CPU/GPU/SoC/DRAM/NAND) et à le trier en catégories
(« bins ») en fonction de ce qu’il peut faire de manière fiable : fréquence à une tension donnée, fuites/consommation, comportement thermique, fonctionnalités activées,
et taux d’erreurs. Ces bins deviennent des SKU et des niveaux de prix différents. Une même conception de die peut être expédiée comme une pièce haut de gamme, une pièce moyenne
avec fréquences réduites, ou une pièce basse avec des cœurs/cache désactivés. L’objectif est le rendement : vendre autant de wafer que possible sans expédier des pièces qui vont échouer,
se mettre en limitation ou violer les enveloppes de puissance.
Du wafer à cinq niveaux : le pipeline
Le binning commence bien avant que votre feuille d’achat voie un numéro de pièce. Il débute sur un wafer, avec des centaines (ou milliers)
de copies de la même conception gravées dans le silicium. Dans un univers parfait, chaque die se comporterait de la même manière. Dans l’univers où
nous opérons réellement, la variation de fabrication est garantie et les défauts sont inévitables.
1) Fabrication du wafer et variation
Un nœud de procédé moderne empile la complexité : transistors minuscules, multiples couches métalliques, silicium sous contrainte, structures de « fin » ou nanosheets,
et lithographie agressive. De petites différences de largeur de ligne, de concentration d’impuretés et d’épaisseur de couche changent le comportement des transistors.
Cela se traduit par des différences réelles de fréquence stable maximale, de consommation et de chaleur. On ne « répare » pas cela ; on le gère.
2) Wafer sort (probe test)
Avant que les dies ne soient séparés, des équipements de test automatisés sondent chaque die. C’est ici que l’on trouve les défauts grossiers et que l’on mesure les paramètres de base.
Le fabricant apprend quels dies sont morts, lesquels sont marginaux et lesquels sont excellents. Cette étape est aussi une rétroaction pour le contrôle du procédé : si le bord d’un wafer est
systématiquement moins bon, vous le verrez immédiatement.
3) Découpe, encapsulation et surprises associées
Après la découpe, un die est encapsulé : fixé, câblé ou bumpé, et enfermé. L’encapsulation n’est pas une étape neutre. Elle introduit de nouvelles contraintes : résistance thermique,
contraintes mécaniques et différences d’intégrité du signal. Un die qui paraissait excellent sur le wafer peut se comporter différemment une fois encapsulé et soumis à des tensions réelles et de la chaleur.
4) Test final, burn-in (parfois) et attribution de SKU
Le test final est l’endroit où l’histoire du SKU s’écrit. Le fournisseur exécute des motifs de test, valide les blocs fonctionnels, vérifie les fusibles, et
confirme que la pièce respecte la spécification : cibles de fréquence, cibles de puissance et exigences fonctionnelles. Ensuite elle reçoit une étiquette :
top bin, mid bin, « salvage » ou mise au rebut.
Voilà la version ligne de production. La version business est brute : le fabricant veut maximiser le revenu par wafer tout en gardant les taux de panne et les coûts de garantie sous contrôle.
Le binning est la manière de concilier ces objectifs.
Pourquoi les dies ne sont pas identiques (et pourquoi cela vous concerne)
Si vous gérez des systèmes de production, le binning compte pour deux raisons : la variance et les contraintes.
La variance signifie « même SKU, comportement différent ». Les contraintes signifient « la spec est un contrat, pas une promesse d’uniformité ».
La variation de fabrication devient variance de puissance, chaleur et boost
Les puces diffèrent par leur courant de fuite. La fuite est la consommation qui ne réalise pas de commutation utile. Plus de fuite signifie plus de chaleur au repos
et en charge, et moins de marge pour le turbo/boost sans dépasser les limites de puissance. Deux CPU peuvent être tous deux « dans la spec » tandis que l’un chauffe
plus et booste moins parce qu’il fuit davantage.
Des marges échangées entre tension, fréquence et erreurs
La performance que vous observez est le résultat d’un compromis négocié entre la physique et le firmware. Les fournisseurs définissent des courbes tension-fréquence,
des limites de puissance et des algorithmes de boost basés sur la caractérisation. Si un die est marginal à haute fréquence, il est soit binned plus bas soit expédié avec des limites conservatrices.
S’il est excellent, il peut être vendu plus haut ou utilisé pour atteindre un SKU TDP/horloge exigeant. Parfois c’est le même silicium avec une carte de fusibles et une configuration firmware différentes.
Pourquoi cela importe en exploitation
Sur le terrain, le binning se manifeste par :
- Différentes fréquences soutenues toutes cœurs entre des nœuds « identiques ».
- Throttling thermique sur un sous-ensemble d’hôtes avec le même design de refroidissement.
- Signatures d’erreurs différentes : ECC corrigé, machine checks corrigés, ou réentraînements de lien.
- Différents ratios « puissance → performance » qui perturbent la planification de capacité.
L’objectif du fournisseur est d’expédier des pièces qui respectent la spec. Votre objectif est d’exploiter un parc prévisible. Ces objectifs se recoupent, mais ils ne sont
pas identiques.
Le schéma en cinq niveaux : comment un die devient cinq SKU
« Un die devient cinq niveaux de prix » n’est pas une loi littérale ; c’est un motif récurrent. Le nombre exact varie, mais cinq est courant
parce que cela se cartographie bien à : flagship, high, mid, low, salvage. Voici comment cela se déroule typiquement.
Tier 1 : Le bin flagship (la diapositive marketing)
Ces dies atteignent la meilleure combinaison de haute fréquence, faible fuite et comportement stable aux tensions cibles. Ils peuvent maintenir
un boost plus élevé dans la même enveloppe de puissance et sont moins susceptibles d’atteindre les limites thermiques dans des configurations typiques.
Le fournisseur peut les vendre à prix premium parce que la performance est facile à démontrer et les marges sont attractives.
Tier 2 : Le high bin (toujours excellent, juste pas la star)
Légèrement pire en fuite, légèrement moins stable à haute fréquence, ou un bloc fonctionnel qui est correct mais pas idéal. Toujours totalement activé, toujours rapide,
mais il peut nécessiter une tension plus élevée pour la même fréquence, entraînant une consommation plus importante en charge. En serveurs, cela signifie souvent qu’il booste,
mais qu’il est plus sensible au refroidissement et aux limites de puissance.
Tier 3 : Le mainstream bin (où le volume vit)
C’est le centre de la distribution : respecte la spec confortablement à des horloges modérées. C’est généralement le meilleur rapport qualité-prix parce qu’il est tarifé pour le volume
et dispose d’une marge raisonnable. Si vous achetez pour un comportement de flotte prévisible, ce niveau se comporte souvent mieux que les bins de bord car il n’est pas poussé aux limites.
Tier 4 : Le low bin (downclocké, downvolté ou fonctionnellement limité)
Ces dies tiennent peut-être mal les hautes fréquences à des tensions raisonnables, ou sont plus fuyards et violeraient les limites de puissance à haute fréquence.
La solution est simple : abaisser les fréquences de base/boost, appliquer des limites de puissance plus strictes, ou les deux. Dans certaines gammes produits, ce niveau est aussi
là où des défauts mineurs sont gérés en désactivant un bloc (un cœur, une tranche de cache, une unité de calcul GPU).
Tier 5 : Le salvage (le tas « encore utile »)
Le salvage est l’endroit où l’économie du rendement devient visible. Un die peut avoir un cœur défectueux, un segment de cache défaillant ou une voie d’interconnexion faible.
Si la conception supporte la redondance ou la désactivation, le fournisseur peut fusiblement couper les parties défaillantes et vendre le reste comme un SKU inférieur.
Le salvage peut être un produit parfaitement fiable lorsqu’il est bien validé. Il peut aussi être l’endroit où les marges deviennent faibles et où la validation est stricte — vous devez donc
adopter des conditions d’exploitation conservatrices en production.
Voilà pourquoi « même die » ne signifie pas « même puce ». La conception du die est un plan ; le produit expédié est le plan plus les résultats de test plus la configuration fuseée plus la politique firmware.
Blague n°1 : Si vous vous sentez inutile, rappelez-vous que quelqu’un a déjà validé un mode « gaming » qui ne faisait que changer la couleur RGB et la courbe des ventilateurs.
Ce qui est mesuré pendant le binning
Les tests varient selon le fournisseur et le produit, mais les dimensions sont cohérentes. Si vous vous êtes déjà demandé pourquoi votre « TDP » ne correspond pas à la consommation murale,
ou pourquoi le boosting est imprévisible, c’est parce que plusieurs contraintes sont gérées simultanément.
Correction fonctionnelle
D’abord : est-ce que ça fonctionne ? Les fournisseurs exécutent des tests logiques, des chaînes de scan et des autotests. Si un bloc échoue, il est soit mis au rebut soit désactivé
(si le produit permet le salvage). Dans les GPU, désactiver quelques unités de calcul est une voie de salvage classique. Dans les CPU, ce sont souvent des cœurs ou des tranches de cache,
selon l’architecture.
Fréquence en fonction de la tension (courbes V/F)
La fréquence maximale stable d’une puce dépend de la tension et de la température. Les fournisseurs construisent des tables tension-fréquence par pièce, parfois avec variation par cœur.
Le meilleur silicium atteint des fréquences plus élevées à une tension plus faible (ou la même fréquence à une puissance inférieure). Cela devient la base pour répartir les bins.
Fuite et puissance
La fuite varie largement. Les pièces à forte fuite peuvent atteindre les cibles de fréquence mais dépasser les limites de puissance, les rendant inadaptées aux SKU haut de gamme.
Les niveaux inférieurs peuvent accepter une fuite plus importante en limitant les horloges ou en étant vendus sur des marchés avec des enveloppes de puissance moins strictes.
Comportement thermique et sensibilité aux points chauds
Un die au mauvais comportement thermique peut atteindre les limites thermiques plus rapidement. La qualité de l’encapsulation et l’application du TIM comptent aussi. Le binning
ne peut pas magiquement réparer un refroidisseur faible, mais il peut réduire la probabilité qu’une puce devienne l’exception thermique qui compromet votre flotte uniforme.
Marges de l’interface mémoire
Le contrôleur mémoire intégré et le PHY sont souvent une dimension de binning. Une pièce peut être vendue avec prise en charge d’une vitesse mémoire inférieure
ou nécessiter des marges de timing plus conservatrices. Sur serveurs, les problèmes de stabilité mémoire sont coûteux : la corruption silencieuse des données est une catastrophe.
Qualité des interconnexions et des voies I/O
PCIe et les liaisons haut débit ont des marges d’intégrité de signal. Les fournisseurs peuvent certifier certaines vitesses de lien basées sur des diagrammes en œil mesurés
ou des taux d’erreur. Certaines pièces sont binned à des taux de lien plus faibles ou à moins de voies validées.
Comportement d’erreur sous stress
Surtout pour les pièces serveur, les taux d’erreurs corrigées sous stress peuvent influencer le binning. La barre n’est pas « zéro erreurs corrigées pour toujours ».
La barre est « dans des limites acceptables pour la charge de travail et le modèle de garantie ». Votre barre peut être plus stricte, et c’est autorisé.
Faits intéressants et contexte historique
- La gestion du rendement précède les CPU modernes. La fabrication des semi-conducteurs a rapidement appris que vendre seulement les dies parfaits rend l’économie impossible.
- Le gradage par vitesse est devenu visible aux consommateurs dans les années 1990. L’idée qu’une même conception puisse être livrée à différentes vitesses d’horloge est devenue courante avec les CPU PC.
- Le « harvesting » des blocs fonctionnels est une vieille astuce. Les puces mémoire et les CPU utilisent depuis longtemps la redondance ou des fusibles de désactivation pour sauver du silicium partiellement défectueux.
- Les fusibles laser et eFuses ont facilité la segmentation. Les puces modernes peuvent configurer de manière permanente des fonctionnalités après fabrication, permettant la diversité SKU à partir d’un même jeu de masques.
- Les dies en bord de wafer se comportent souvent différemment. La variation de procédé à travers un wafer peut créer des motifs spatiaux ; les données de test sont cartographiées pour identifier les problèmes systémiques.
- L’encapsulation peut changer le bin. Un die qui passe la sonde sur wafer peut échouer au test final après encapsulation à cause du stress, des thermiques ou des changements d’intégrité du signal.
- La DRAM et la NAND sont fortement binées aussi. Les fournisseurs de mémoire font du binning selon la vitesse, la latence et les taux d’erreur ; les vendeurs de SSD binent la NAND selon l’endurance et la performance.
- Les SKU serveur privilégient souvent l’efficacité énergétique plutôt que les pics d’horloge. Les datacenters payent pour les watts et le refroidissement ; un bin « plus lent » peut être un meilleur produit opérationnel.
- Le turbo/boost est en pratique un binning dynamique au runtime. Les CPU modernes décident en continu à quel point ils peuvent fonctionner proches des limites compte tenu de la température, de la puissance et de la charge.
Trois micro-récits d’entreprise tirés du terrain
Micro-récit 1 : L’incident causé par une mauvaise hypothèse (SKU = comportement)
Une entreprise a déployé un nouveau lot de nœuds de calcul pour un service sensible à la latence. Les achats ont fait la « bonne » chose : même fournisseur,
même numéro de modèle, même stepping (autant qu’ils pouvaient le voir), mêmes paramètres BIOS, même agencement de rack. Le service a tout de même développé
un problème étrange de latence extrême qui n’apparaissait que lors de pics régionaux de trafic.
L’équipe on-call a chassé les suspects habituels : pauses GC, voisins bruyants, régressions du planificateur du noyau. Rien. Les métriques montraient qu’un sous-ensemble
d’hôtes tournait quelques degrés de plus et soutenait une fréquence all-core légèrement inférieure sous charge maximale. Pas assez pour déclencher des alarmes. Suffisant pour étirer le p99.
La mauvaise hypothèse était subtile : « même SKU implique même performance soutenue ». En réalité, ils avaient plusieurs bins silicium sous le même label SKU à cause des réalités de la chaîne d’approvisionnement.
Dans la spec, oui. Uniforme, non. Sous la politique de plafonnement de puissance du service, les pièces plus fuyantes atteignaient les limites de puissance plus tôt et réduisaient le boost,
devenant des valeurs aberrantes systématiques en tail.
La correction n’était pas exotique. Ils ont créé une étape de burn-in et de caractérisation pour les nouveaux nœuds, enregistrant la fréquence soutenue sous une charge standardisée,
ainsi que la puissance et la température. Les nœuds qui entraient dans le cluster « chaud/faible » ont été affectés à des charges par lots, pas aux pools sensibles à la latence.
Même SKU. Destin différent. La production s’est calmée.
Micro-récit 2 : L’optimisation qui a mal tourné (tuning de puissance rencontre la loterie du silicium)
Une autre organisation voulait réduire les coûts énergétiques. Ils ont appliqué un undervolting agressif et resserré les limites de puissance sur une flotte,
basé sur des tests en labo de quelques serveurs représentatifs. Les benchmarks semblaient excellents : moins de watts, presque le même débit, et une jolie diapositive pour la direction.
En production, le changement s’est comporté comme une catastrophe polie. Une fraction de nœuds a commencé à montrer des erreurs machine check corrigées sous charge.
Puis une plus petite fraction a évolué vers des erreurs non corrigées et des redémarrages spontanés — rares, mais toujours aux pires heures. L’impact sur le niveau de service était petit mais récurrent,
ce qui érode les équipes sur des mois.
Le mécanisme du retour de flamme : l’undervolt a réduit la marge de bruit sur le silicium marginal. Les unités labo étaient de meilleurs bins ; la flotte incluait une distribution comprenant des dies plus faibles.
Les erreurs étaient « corrigées » jusqu’à ce qu’elles ne le soient plus, et la télémétrie d’erreur a d’abord été ignorée parce que « corrigée » sonnait comme « OK ».
L’équipe a annulé l’undervolt, gardé une réduction de puissance modeste, et ajouté une garde : tout nœud avec un taux d’erreurs corrigées au-dessus d’un seuil est automatiquement retiré du pool et testé.
Ils ont finalement réintroduit un réglage par nœud basé sur la stabilité mesurée, pas sur des espoirs.
Micro-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (l’hygiène de flotte gagne)
Un service riche en stockage exécutait des charges mixtes : compaction, chiffrement et streaming à haut débit. Ils se sont standardisés sur un SKU CPU pour simplifier.
Mais ils faisaient une chose ennuyeuse de manière consistante : ils enregistraient le modèle CPU, la version microcode, les paramètres BIOS de puissance et la télémétrie machine-check dans leur système d’inventaire,
et ils ne sautaient jamais les tests de burn-in pour les nouveaux racks.
Des mois plus tard, une nouvelle livraison est arrivée pendant une pénurie d’approvisionnement. Même SKU sur le papier, mais le comportement en charge était légèrement différent :
la consommation était plus élevée et le boost moins stable. La différence était dans la spec, mais elle comptait pour leur enveloppe thermique.
Parce qu’ils avaient des baselines, ils ont détecté le déplacement dès le premier jour. Ils n’ont pas accusé l’application. Ils n’ont pas accusé le noyau.
Ils ont corrélé le changement avec des lots de fabrication et des réglages firmware, puis mis à jour le placement en rack et les courbes de ventilateurs pour cette cohorte.
Le déploiement s’est poursuivi sans franchir les seuils de throttling thermique.
Personne n’a été promu pour « nous avons remarqué une dérive de distribution et ajusté les politiques ». Mais personne n’a reçu d’alerte à 3 h du matin non plus. C’est le
genre de travail ennuyeux qui paie.
Tâches pratiques : commandes, sorties et décisions
Vous ne pouvez pas « voir les bins » directement sans les données de test du fournisseur, mais vous pouvez observer les conséquences : comportement de fréquence, limites de puissance,
marge thermique et taux d’erreurs. Ci‑dessous des tâches pratiques à exécuter sur des serveurs Linux pour caractériser et gérer la variance induite par le binning.
Chacune inclut : une commande, une sortie d’exemple, ce que cela signifie, et quelle décision prendre.
Tâche 1 : Identifier le modèle CPU, le stepping et le microcode
cr0x@server:~$ lscpu | egrep 'Model name|Stepping|CPU\(s\)|Thread|Socket|Vendor|MHz'
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU(s): 64
Thread(s) per core: 2
Socket(s): 2
Stepping: 6
CPU MHz: 2000.000
Signification de la sortie : Confirme ce que vous pensez avoir acheté et si plusieurs steppings existent dans la flotte.
Décision : Si vous voyez des steppings mixtes ou des modèles inattendus sous le même bon de commande, séparez les pools et établissez des baselines séparées.
Tâche 2 : Vérifier la version du microcode et si les mises à jour sont appliquées
cr0x@server:~$ grep -m1 microcode /proc/cpuinfo
microcode : 0x2d
Signification de la sortie : Le microcode impacte le comportement de boost et les marges de stabilité. Des versions différentes peuvent changer la performance et les taux d’erreur.
Décision : Standardisez le microcode sur la flotte avant de comparer le « comportement de bin ». Sinon vous comparez des pommes avec du firmware.
Tâche 3 : Voir la politique du gouverneur de fréquence CPU actuelle
cr0x@server:~$ cpupower frequency-info | sed -n '1,18p'
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 3500 MHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3500 MHz.
The governor "powersave" may decide which speed to use
current CPU frequency: 1200 MHz (asserted by call to hardware)
Signification de la sortie : Indique si le système est autorisé à booster ou s’il est limité par la politique.
Décision : Pour les essais de caractérisation, utilisez un gouverneur cohérent (souvent performance) pour réduire le bruit lors de la comparaison des nœuds.
Tâche 4 : Verrouiller le gouverneur sur performance pour un test contrôlé
cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Signification de la sortie : Le gouverneur a changé. La machine favorisera des fréquences plus élevées.
Décision : Si votre flotte s’appuie sur des gouverneurs d’économie d’énergie, ne changez pas les paramètres par défaut en production globalement ; utilisez ceci seulement pendant les tests ou dans des pools dédiés.
Tâche 5 : Observer les fréquences par cœur sous charge (vérification rapide)
cr0x@server:~$ sudo turbostat --quiet --show CPU,Avg_MHz,Busy%,Bzy_MHz,PkgWatt,PkgTmp --interval 2 --num_iterations 3
CPU Avg_MHz Busy% Bzy_MHz PkgWatt PkgTmp
- 2860 92.3 3099 182.40 78
- 2795 93.1 3003 179.10 80
- 2712 94.0 2886 176.85 82
Signification de la sortie : Bzy_MHz décroît à mesure que la température augmente ; la puissance reste proche d’un plafond.
Décision : Si le Bzy_MHz soutenu diffère sensiblement entre des nœuds « identiques », traitez-les comme des bins de performance différents pour l’ordonnancement.
Tâche 6 : Vérifier le throttling thermique et les capteurs de température
cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +82.0°C (high = +90.0°C, crit = +100.0°C)
Core 0: +79.0°C (high = +90.0°C, crit = +100.0°C)
Core 1: +80.0°C (high = +90.0°C, crit = +100.0°C)
Signification de la sortie : Vous êtes proche des seuils « high » ; de petites différences de bin peuvent vous faire basculer en throttling.
Décision : Si une cohorte fonctionne systématiquement plus chaude, ajustez les courbes de ventilateurs, le placement en rack ou l’affectation des charges avant d’accuser l’application.
Tâche 7 : Inspecter les logs du noyau pour machine-check et erreurs matérielles corrigées
cr0x@server:~$ sudo journalctl -k -b | egrep -i 'mce|machine check|edac|hardware error' | tail -n 8
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: CPU 17: Machine Check: 0 Bank 7: b200000000070005
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: PROCESSOR 0:50656 TIME 1705025643 SOCKET 0 APIC 34 microcode 2d
Signification de la sortie : Des erreurs matérielles existent. Même si « corrigées », elles sont un indicateur avancé de conditions marginales tension/fréquence/thermiques.
Décision : Mettre en quarantaine les nœuds avec des erreurs corrigées récurrentes ; enquêter sur le refroidissement, le microcode et tout tweak d’undervolt/power.
Tâche 8 : Vérifier les compteurs EDAC (ECC mémoire)
cr0x@server:~$ sudo edac-util -v
mc0: 2 Uncorrected Errors with no DIMM info
mc0: 37 Corrected Errors with no DIMM info
Signification de la sortie : Des erreurs corrigées se produisent ; les erreurs non corrigées sont une alerte critique.
Décision : Des rafales corrigées suggèrent une marge mémoire marginale ou un DIMM en dégradation ; planifiez un remplacement et validez la politique de vitesse mémoire pour cette cohorte CPU.
Tâche 9 : Confirmer la vitesse mémoire réellement utilisée (et si elle est down-binned)
cr0x@server:~$ sudo dmidecode -t memory | egrep 'Speed:|Configured Memory Speed:' | head -n 10
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Signification de la sortie : Les DIMM supportent 3200, mais la plateforme les fait tourner à 2933 (peut-être limites IMC CPU, règles de population, ou BIOS).
Décision : Si un nouveau lot tourne silencieusement à une vitesse mémoire inférieure, revérifiez les contraintes de stepping/bin CPU et les règles de population BIOS ; ajustez les attentes et les plans de capacité.
Tâche 10 : Mesurer les limites de puissance du package (cause fréquente de « pourquoi ça ne booste pas ? »)
cr0x@server:~$ sudo rdmsr -a 0x610 | head -n 4
00000000f8c800f8
00000000f8c800f8
00000000f8c800f8
00000000f8c800f8
Signification de la sortie : Valeur MSR brute encodant les limites de puissance (PL1/PL2) sur certaines plateformes Intel.
Décision : Si différentes cohortes montrent des réglages PL différents, standardisez la politique BIOS de puissance ou séparez les pools ; ne comparez pas la performance tant que les limites ne correspondent pas.
Tâche 11 : Confirmer les limites de fréquence CPU exposées à l’OS
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
3500000
Signification de la sortie : Fréquence max en kHz. Si elle est plus basse que prévue, vous pouvez être plafonné par le BIOS, la politique de puissance, ou un mode contrainte thermique.
Décision : Si cela diffère entre des nœuds du même SKU, traitez-le comme un incident de dérive de configuration.
Tâche 12 : Test de charge pour comportement soutenu (pas seulement turbo en rafale)
cr0x@server:~$ stress-ng --cpu 0 --cpu-method matrixprod --timeout 60s --metrics-brief
stress-ng: info: [22118] setting to a 60 second run per stressor
stress-ng: metrc: [22118] stressor bogo ops real time usr time sys time bogo ops/s
stress-ng: metrc: [22118] cpu 6823 60.02 59.81 0.11 113.7
Signification de la sortie : Un proxy de débit rapide. À utiliser avec turbostat pour voir le throttling puissance/thermique.
Décision : Si le débit diverge significativement entre des nœuds avec les mêmes réglages, créez une carte de cohortes et planifiez en conséquence.
Tâche 13 : Inspecter l’état du lien PCIe (la marge I/O peut ressembler à un « stockage lent »)
cr0x@server:~$ sudo lspci -vv -s 3b:00.0 | egrep 'LnkCap:|LnkSta:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x16 (ok)
Signification de la sortie : Le lien s’est entraîné à 8GT/s. Cela peut être l’intégrité du signal, le BIOS, ou une voie marginale.
Décision : Si une cohorte se downgrade systématiquement, ne « optimisez » pas le logiciel. Corrigez le câblage, le choix du slot, le firmware, ou RMA l’hôte si c’est persistant.
Tâche 14 : Confirmer la topologie NUMA et la localité mémoire (le binning rencontre la topologie)
cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 257642 MB
node 0 free: 192110 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 257919 MB
node 1 free: 198844 MB
Signification de la sortie : Deux nœuds NUMA. Un mauvais placement peut imiter une performance de « mauvais bin ».
Décision : Si seuls certains hôtes semblent lents, vérifiez le pinning NUMA et la localité mémoire avant d’accuser le silicium.
Tâche 15 : Vérifier le throttling des cgroups CPU (n’accusez pas la puce pour vos limites)
cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
usage_usec 912345678
user_usec 900000000
system_usec 12345678
nr_periods 56012
nr_throttled 8421
throttled_usec 98765432
Signification de la sortie : La charge est throttlée par des quotas cgroup.
Décision : Si vous voyez du throttling, corrigez d’abord les limites de ressources ou l’ordonnancement ; sinon vous attribuerez incorrectement la variance de performance au binning.
Tâche 16 : Repérer des « clusters de bin » au niveau flotte via une comparaison simple
cr0x@server:~$ awk -F: '/model name/ {m=$2} /microcode/ {u=$2} END {gsub(/^[ \t]+/,"",m); gsub(/^[ \t]+/,"",u); print m " | microcode " u}' /proc/cpuinfo
Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz | microcode 0x2d
Signification de la sortie : Un fait d’inventaire bon marché que vous pouvez collecter partout.
Décision : Combinez avec des baselines puissance/temp/perf. Si vous voyez plusieurs cohortes microcode, alignez-les avant de tirer des conclusions sur des différences de bin.
Blague n°2 : Votre modèle de capacité est seulement « déterministe » jusqu’à ce que vous rencontriez le seul serveur qui booste comme s’il payait son loyer par watt.
Mode opératoire de diagnostic rapide
Quand un sous-ensemble de nœuds est plus lent/plus chaud/plus instable et que vous suspectez des effets de « binning », vous avez besoin d’un moyen rapide pour trouver le goulot réel.
Voici le playbook que j’utilise.
Première étape : éliminer la dérive de configuration et les plafonds artificiels
- Gouverneur/politique : confirmer que
cpupower frequency-infoest cohérent. - Limites de puissance : vérifier les réglages BIOS (et si disponible, la télémétrie des limites de puissance).
- Politique thermique : assurer que les courbes de ventilateurs et le flux d’air sont identiques ; vérifier poussière et caches bloqués.
- Throttling cgroup : vérifier que vous ne quotaez pas différemment les nœuds « lents ».
Deuxième étape : vérifier thermiques et puissance sous charge soutenue
- Exécutez une charge contrôlée de 5–10 minutes (par ex.,
stress-ng). - Capturez
turbostatpourBzy_MHz,PkgWattetPkgTmp. - Comparez les cohortes. Si la puissance atteint un plafond pendant que la fréquence chute, vous êtes limité par la puissance. Si la température atteint « high », vous êtes limité thermiquement.
Troisième étape : chercher erreurs corrigées et downtraining I/O
- MCE/EDAC corrigés : les erreurs corrigées récurrentes ne sont pas « OK », ce sont des pré‑pannes.
- Vitesse lien PCIe : le downtraining peut diviser par deux la bande passante I/O et ressemble à une régression stockage/réseau.
- Vitesse mémoire : confirmez que la vitesse mémoire configurée n’a pas chuté sur un nouveau lot.
Quatrième étape : prendre une décision rapidement
- Si c’est de la configuration : corrigez la dérive et re-baselinez.
- Si c’est thermique : ajustez le flux d’air, le placement ou dégradez la cohorte.
- Si c’est une stabilité marginale : retirez des pools sensibles et engagez le support fournisseur/RMA.
- Si c’est la variance normale de bin : planifiez intelligemment ; arrêtez de prétendre que la flotte est homogène.
Erreurs courantes : symptômes → cause profonde → correction
1) Symptomatique : « Même SKU, mais certains nœuds sont 5–10% plus lents en charge »
Cause profonde : différences de limites de puissance, marge thermique différente, ou variance de fuite interagissant avec vos plafonds de puissance.
Correction : standardisez la politique BIOS de puissance ; établissez une baseline avec turbostat ; regroupez les nœuds par fréquence/power soutenu ; planifiez le travail sensible à la latence sur la meilleure cohorte.
2) Symptomatique : « Après undervolting, des erreurs corrigées apparaissent, puis des redémarrages occasionnels »
Cause profonde : l’undervolt a supprimé la marge de bruit ; les bins plus faibles échouent en premier.
Correction : annuler l’undervolt ; réintroduire uniquement après qualification par nœud et garde‑fous sur le taux d’erreurs ; traiter les erreurs corrigées comme de la télémétrie exploitable.
3) Symptomatique : « Nouveau lot chauffe plus, ventilateurs plus bruyants, mais performance identique ou pire »
Cause profonde : cohorte de silicium plus fuyante ou variation d’encapsulation ; même spec, efficacité différente.
Correction : comparez PkgWatt et PkgTmp sous charge contrôlée ; ajustez placement en rack, flux d’air et affectation de pool pour la nouvelle cohorte.
4) Symptomatique : « Débit stockage en baisse ; CPU semble inactif »
Cause profonde : lien PCIe downtrainé (marge d’intégrité du signal), ou firmware ayant changé la politique de lien.
Correction : vérifiez avec lspci -vv ; reseatez les cartes, vérifiez risers/câbles, mettez à jour le firmware, isolez la cohorte ; RMA si persistant.
5) Symptomatique : « Les rafales de benchmark sont excellentes, la charge soutenue en production est mauvaise »
Cause profonde : le comportement turbo masque le throttling soutenu dû aux limites de puissance/thermiques.
Correction : testez en soutenu (minutes, pas secondes) tout en enregistrant turbostat et les températures ; tunez pour le comportement soutenu, pas pour les chiffres marketing de boost.
6) Symptomatique : « Seul un sous-ensemble de nœuds montre des erreurs ECC corrigées »
Cause profonde : différences de marge de l’interface mémoire, vieillissement des DIMM, ou différences d’entraînement mémoire BIOS interagissant avec une cohorte silicium.
Correction : validez la vitesse mémoire configurée, exécutez des diagnostics mémoire, échangez des DIMM entre nœuds pour isoler plateforme vs DIMM, et gardez des réglages mémoire conservateurs pour cette cohorte.
7) Symptomatique : « Les graphiques de performance ressemblent à un peigne : certains nœuds consistent en haut, d’autres en bas »
Cause profonde : vous avez plusieurs bins effectifs dans le même pool.
Correction : arrêtez de faire un équilibrage naïf ; ajoutez un scoring des nœuds basé sur perf/watt soutenu et télémétrie d’erreur ; partitionnez les pools par cohorte.
Listes de contrôle / plan étape par étape
Plan étape par étape : transformer le binning du chaos en faits d’inventaire
- Collecter l’identité matérielle de manière cohérente. Modèle, stepping, microcode, version BIOS, config mémoire, topologie NIC/PCIe.
- Définir un profil de burn-in standard. Une charge CPU soutenue, une charge mémoire, et un contrôle I/O. Gardez-le ennuyeux et répétable.
- Capturer trois métriques par nœud : fréquence all-core soutenue, puissance package, et température maximale pendant la fenêtre de burn-in.
- Enregistrer les compteurs d’erreurs corrigées. MCE et EDAC. Suivre les deltas, pas seulement les valeurs absolues.
- Clusteriser les nœuds en cohortes. Pas à la sensation — par comportement mesuré.
- Affecter les charges selon les caractéristiques des cohortes. Sensible à la latence sur les cohortes froides/efficaces ; batch sur les cohortes chaudes/fuyantes.
- Définir des garde‑fous. Tout nœud dépassant les seuils d’erreurs corrigées quitte automatiquement le pool.
- Standardiser le firmware. Les réglages BIOS et le microcode doivent être cohérents avant de comparer les cohortes dans le temps.
- Communiquer la réalité des achats. « Même SKU » n’est pas une garantie de performance soutenue identique. Faites-en une hypothèse écrite dans la planification de capacité.
- Revoir trimestriellement. Les distributions de silicium évoluent entre lots de fabrication ; le comportement de votre flotte dérivera si vous ne continuez pas à mesurer.
Checklist faire / éviter (édition ops)
- Faire : mesurer le comportement soutenu sous votre politique de puissance réelle. Éviter : se fier à un pic de benchmark de 30 secondes.
- Faire : traiter les erreurs matérielles corrigées comme un signal. Éviter : attendre des erreurs non corrigées pour « prouver » un problème.
- Faire : séparer les cohortes quand nécessaire. Éviter : forcer un modèle d’ordonnancement homogène sur un silicium hétérogène.
- Faire : conserver des réglages conservateurs pour les bins avec beaucoup de salvage. Éviter : appliquer des undervolts agressifs à toute la flotte.
FAQ
1) Le binning n’est-il qu’un moyen de faire payer plus pour la même puce ?
En partie. C’est aussi la manière pour les fabricants de vendre plus de chaque wafer. Sans binning, on mettrait à la casse beaucoup de silicium qui est parfaitement utilisable
à une horloge inférieure ou avec un bloc désactivé. Les prix suivent la performance et la demande, mais le moteur sous-jacent est l’économie du rendement.
2) Les bins de niveau supérieur sont-ils toujours plus fiables ?
Pas automatiquement. Les pièces haut de gamme peuvent fonctionner plus près des limites de performance (horloges plus élevées, densité de puissance plus élevée), ce qui peut
solliciter le refroidissement et la distribution d’alimentation. La fiabilité est une propriété système : silicium + firmware + carte + refroidissement + charge.
3) Pourquoi deux CPU du même numéro de modèle boostent-ils différemment ?
Parce que le boost est contraint par la puissance, la température et des caractéristiques silicium comme la fuite. Même au sein d’un SKU, les pièces peuvent avoir des courbes V/F différentes.
Ajoutez des différences BIOS, des versions de microcode et des variations de refroidissement, et le « même » CPU devient une distribution.
4) Le silicium salvage est-il du « mauvais » silicium ?
Pas nécessairement. Salvage signifie « certains blocs ont été désactivés ». Les blocs restants peuvent être parfaitement fiables s’ils sont correctement validés.
Mais vous devriez supposer moins de marge et être conservateur avec les undervolts, l’overclock mémoire et les enveloppes thermiques serrées.
5) Puis-je détecter mon bin exact en tant qu’utilisateur final ?
Habituellement non. Les fournisseurs n’exposent pas l’identité du bin directement. Vous pouvez inférer le comportement : fréquence soutenue à une limite de puissance donnée,
exigences de tension, thermiques et taux d’erreurs. Pour l’exploitation, l’inférence suffit pour prendre des décisions d’ordonnancement et d’achat.
6) La « loterie du silicium » est-elle réelle ou folklore internet ?
La variation est réelle. La partie folklore est la croyance que vous pouvez systématiquement « gagner » avec des tactiques grand public. En production, vous ne pariez pas ; vous mesurez,
vous clusterisez et vous planifiez. Miser vos SLO sur la loterie est un choix de carrière étrange.
7) Comment le binning se rapporte-t-il au TDP ?
Le TDP est une cible de conception thermique/puissance, pas une promesse de consommation murale. Le binning décide quel silicium peut atteindre un certain niveau de performance
dans une enveloppe TDP. Les algorithmes de boost runtime travaillent alors dans ces limites (et parfois les contournent).
8) Le microcode influence-t-il le binning ?
Le binning est fait en fabrication, mais le microcode influence la manière dont le CPU exploite ses marges sur le terrain. Les mises à jour peuvent changer la politique de boost,
atténuer des errata et modifier la performance. Si vous comparez des cohortes, alignez le microcode d’abord.
9) Pourquoi un fournisseur expédierait-il le même die avec des fonctionnalités désactivées plutôt que de fabriquer un die plus petit ?
Les jeux de masques coûtent cher, la validation coûte cher, et le time‑to‑market est impitoyable. Expédier une conception de die unique et segmenter via des fusibles réduit la complexité
et améliore l’économie du rendement. Des dies plus petits peuvent apparaître plus tard comme dérivés optimisés pour le coût.
10) Quelle est la meilleure réponse opérationnelle à la variance de binning ?
Traitez le matériel comme vous traitez les réseaux : mesurez, modélisez des distributions, et construisez des garde‑fous. Utilisez des baselines burn-in, un ordonnancement conscient des cohortes,
et des seuils de télémétrie d’erreurs. N’assumez pas l’uniformité parce que les achats ont bien fait leur travail.
Conclusion : prochaines étapes réellement utiles
Le binning est la façon dont la fabrication transforme la réalité imparfaite en produits expédiables. Une même conception de die devient cinq niveaux de prix parce que c’est la seule manière raisonnable
d’obtenir du rendement, une segmentation de performance et de la fiabilité dans un budget de garantie. Pour les exploitants, la leçon n’est pas « le fournisseur est malveillant ». La leçon est :
votre flotte est une distribution, et prétendre le contraire vous rendra plus lent, plus chaud et plus surpris.
Les prochaines étapes pratiques :
- Commencez à collecter le stepping CPU, le microcode et les réglages BIOS dans l’inventaire.
- Ajoutez un burn-in court et répétable qui capture fréquence soutenue, puissance et température.
- Suivez les erreurs matérielles corrigées et mettez automatiquement en quarantaine les récidivistes.
- Clusterisez les nœuds en cohortes et affectez les charges en conséquence.
- Standardisez le firmware avant de déclarer un « problème de binning ».
Idée paraphrasée de Werner Vogels : « Tout échoue, tout le temps — concevez et opérez comme si c’était normal. »