PL1, PL2 et Tau expliqués : les trois chiffres qui décident de tout

Le modèle mental : puissance, temps et « pourquoi ça a ralenti ? »

Un CPU est essentiellement un convertisseur puissance→travail enveloppé d’un problème thermique. La fréquence et la tension déterminent la quantité de travail qu’il peut accomplir par seconde.
Mais fréquence et tension déterminent aussi la consommation électrique, et la puissance devient chaleur. La chaleur doit quitter le package, entrer dans le refroidissement,
puis s’échapper vers l’air ambiant. Cette chaîne a des limites.

PL1, PL2 et Tau sont la façon pour le CPU d’être honnête avec la physique tout en laissant le marketing afficher de jolis chiffres de boost.
Ils définissent un budget : combien de puissance le CPU peut dépenser en continu (PL1), combien il peut dépasser brièvement (PL2),
et pendant combien de temps ce dépassement est toléré (Tau). Si vous ne retenez rien d’autre, retenez ceci :
PL2 est votre « rafale », PL1 est votre « état stable », et Tau est la minuterie de patience.

Dans les systèmes de production, ces nombres apparaissent comme :

• Des requêtes démarrent vite, puis la latence en queue augmente après quelques secondes de charge soutenue.
• Les tâches par lot montrent une courbe de débit en « dents de scie » : boost, clamp, récupération, répétition.
• Deux machines « identiques » performent différemment parce qu’un fournisseur de carte mère a décidé d’interpréter « par défaut » de manière créative.
• Les améliorations de refroidissement n’aident pas autant que prévu parce que le système est limité par la puissance, pas par la thermique.

Blague n°1 : Un CPU sans limites de puissance sensées, c’est comme un buffet sans assiettes — tout le monde est enthousiaste jusqu’à ce que le sol soit couvert de pâtes.

Les meilleurs opérateurs traitent les limites de puissance comme tout autre contrôle de production :
définir une cible, l’appliquer de façon cohérente et alerter en cas de dérive. Les « valeurs par défaut » ne sont pas une stratégie.

PL1, PL2, Tau : définitions utilisables en salle d’astreinte

PL1 : limite de puissance à long terme (état stable)

PL1 est la puissance moyenne à long terme que le CPU est autorisé à consommer. Dans beaucoup d’écosystèmes, elle correspond vaguement au TDP,
mais « vaguement » fait beaucoup de travail ici. Si votre charge est soutenue — encodage, compactage, analytique, scan AV, consolidation de VM — PL1 est
le chiffre qui détermine le plafond de performance à long terme.

Quand le CPU atteint PL1, il réduit la fréquence (et parfois la tension) pour maintenir la puissance moyenne du package à ou en dessous de cette limite.
Cela peut arriver même lorsque les températures semblent correctes. C’est un point clé : le throttling par puissance n’est pas toujours un throttling thermique.

PL2 : limite de puissance à court terme (rafale)

PL2 est une limite de puissance plus élevée que le CPU peut utiliser pendant un intervalle court. C’est ce qui rend votre système réactif :
pics d’interface, courtes phases de compilation, requêtes rapides, pointes de trafic éphémères. PL2 est l’endroit où vit le « turbo ».

Si PL2 est configuré de manière agressive et que le refroidissement est médiocre, le CPU va monter fortement en fréquence, chauffer rapidement, puis heurter un autre limiteur :
soit il atteint Tau et retombe vers PL1, soit il atteint des limites thermiques (TJmax, PROCHOT) et chute encore plus fort.

Tau : la fenêtre temporelle (combien de temps PL2 est autorisé)

Tau est la constante de temps / fenêtre qui contrôle combien de temps le CPU peut dépasser PL1 jusqu’à PL2 avant de devoir se restreindre.
En pratique, de nombreuses plateformes l’implémentent par une moyenne glissante de la puissance du package sur une fenêtre temporelle.
Si la puissance moyenne sur cet intervalle dépasse PL1, le CPU réduit la fréquence pour faire redescendre la moyenne.

Le symptôme classique de Tau est : « Tout est rapide pendant 10–60 secondes, puis les performances chutent et restent plus basses. »
Ce n’est pas mystérieux. C’est Tau qui fait exactement ce qu’on lui a demandé.

Une autre définition que vous rencontrerez : « illimité »

Certains BIOS et outils constructeurs proposent un PL2 « illimité » ou un Tau très élevé. Cela signifie généralement « jusqu’à ce que quelque chose d’autre panique »,
pas « pour toujours ». Ce quelque chose d’autre est typiquement la température, les limites de courant VRM, les limites de température de coque, ou les budgets d’alimentation plateforme.
« Illimité » est excellent pour les benchs et terrible pour les systèmes prévisibles.

Comment les CPU appliquent les limites (et pourquoi ça paraît personnel)

Les CPU modernes ont plusieurs couches de gouverneurs et d’arrêts durs. Les limites de puissance sont appliquées par une logique sur la puce utilisant la télémétrie :
estimation de la puissance du package, courant tiré, capteurs de température, et parfois des signaux externes de la plateforme depuis le contrôleur de la carte mère.
Lorsqu’une limite est dépassée, le CPU ne négocie pas. Il bride la fréquence, ajuste la tension, et peut restreindre les paliers turbo.

La hiérarchie d’application varie selon la génération et le fournisseur, mais on retrouve typiquement :

• Throttling par limite de puissance : la puissance du package dépasse PL1/PL2 (souvent rapporté comme « PL1/PL2 » ou « Power Limit »).
• Throttling thermique : la température approche TJmax ; le CPU réduit la fréquence pour rester sous le plafond thermique.
• PROCHOT : signal « processor hot » — peut être asserté par le CPU ou la plateforme ; bridle agressivement.
• Limites de courant/VRM : le VRM de la carte mère ne peut pas fournir le courant demandé ; la distribution d’énergie devient le plafond.
• Limites plateforme : l’EC du portable applique des budgets batterie/adaptateur ; les serveurs appliquent des plafonds d’alimentation rack.

Point opérationnel important : le limiteur que vous voyez n’est pas toujours la cause racine. Une limite de puissance peut provoquer une fréquence plus basse, ce qui réduit la chaleur,
masquant ainsi un problème thermique. Ou un problème thermique peut forcer la fréquence à baisser, ce qui réduit la puissance, donnant l’impression d’être « dans PL1 ».
Vous diagnostiquez en corrélant : fréquence, température, puissance du package et drapeaux de throttling — dans le temps.

Une citation, parce que c’est toujours le meilleur conseil en opérations. Gene Kranz, directeur de vol à la NASA, a dit :
« Dur et compétent. »
En terrain de limites de puissance, « dur » signifie ne pas retoucher les réglages dans la panique ; « compétent » signifie mesurer avant de tourner les boutons.

Ce qui change quand vous ajustez chaque valeur

Augmenter PL1 : meilleur débit soutenu, chaleur stable plus élevée, facture d’électricité plus grosse

Augmenter PL1 augmente la performance soutenue si (et seulement si) le CPU était précédemment limité par la puissance sous votre charge d’état stable.
Cela augmente aussi la charge thermique stable. Si votre refroidissement et le flux d’air du châssis ne peuvent pas évacuer cette chaleur, vous échangerez
le throttling par puissance contre le throttling thermique. Ce n’est pas une amélioration ; c’est un autre type de misère.

Augmenter PL2 : rafales plus réactives, potentiellement moins de stabilité sous charges en pics

PL2 affecte la réactivité et les courts benchs. En serveur, il affecte le comportement en queue lors de pics brefs de charge.
Vous pouvez obtenir de vrais gains pour les services rafales (frontends API, chauffe de cache, courtes étapes de compilation).
Mais si PL2 est trop élevé, vous pouvez déclencher des limites de courant VRM, des limites d’adaptateur (portables), ou des transitoires thermiques qui
font osciller le système. L’oscillation est ce que vos graphiques SLO appellent « intéressant ».

Changer Tau : contrôle le timing de la « falaise »

Tau détermine combien de temps le CPU peut se comporter comme un sprinteur avant d’être forcé à l’allure du marathonien.
Augmenter Tau tend à améliorer l’apparence des benchs et peut aider les charges qui se terminent rapidement.
Cela peut aussi empirer les charges soutenues si cela fait chauffer le système plus tôt, saturer les ventilateurs
et provoquer un throttling thermique ultérieur. C’est pourquoi « augmentez juste Tau » est un mème, pas un plan.

Baisser les limites : un mouvement sous-estimé

En production, baisser PL2 et/ou PL1 peut augmenter la prévisibilité, réduire le bruit des ventilateurs (oui, ça compte dans les bureaux et laboratoires),
et maintenir les systèmes dans les budgets d’alimentation rack. C’est particulièrement utile dans des déploiements denses où un nœud qui part en full turbo
peut pousser une branche PDU dangereusement proche des limites.

Blague n°2 : Mettre PL2 au maximum parce qu’« on a payé pour le turbo » revient à retirer le limiteur de vitesse d’une camionnette de livraison — super jusqu’à ce que les pneus déposent une plainte.

Où vous les réglez compte : BIOS vs OS vs outils constructeur

Vous pouvez définir les limites de puissance dans le BIOS/UEFI, via des interfaces au niveau OS (RAPL sur Intel, profils plateforme, powercap), ou via des démons constructeur.
Le BIOS est généralement le plus stable et le moins surprenant. Le contrôle au niveau OS est puissant mais plus susceptible de dériver avec des mises à jour ou une mauvaise configuration.
Les outils constructeurs sont souvent opaques et parfois « utiles » comme un tout-petit aide à cuisiner.

Faits intéressants et courte histoire

• Les limites de puissance sont devenues grand public quand le turbo l’a été. Le turbo boost a créé le besoin de budgets explicites et applicables au-delà du « TDP ».
• RAPL existe parce qu’on ne peut pas gérer ce qu’on ne mesure pas. Les interfaces Running Average Power Limit d’Intel ont apporté la puissance dans les boucles de contrôle logiciel.
• Les valeurs de Tau s’alignent souvent sur des fenêtres de bench « esthétiques ». Beaucoup de paramètres Tau par défaut tombent dans des plages de dizaines de secondes, ce qui est… pratique.
• Les fournisseurs de cartes mères traitent « defaults Intel » comme une suggestion. Certaines cartes expédient avec PL2/Tau élevés pour gagner des revues, puis votre datacenter paie la facture.
• PL1 n’est pas toujours égal au TDP. Les OEM peuvent régler PL1 au-dessus ou en dessous du TDP nominal selon le refroidissement et les objectifs produit.
• La gestion de la puissance est un problème de plateforme, pas seulement de CPU. Le design du VRM, les limites PSU, le flux d’air du châssis et les contrôleurs embarqués peuvent annuler vos réglages.
• La télémétrie est imparfaite. La puissance du package est souvent estimée, pas mesurée directement, et la précision varie selon la plateforme et l’étalonnage.
• Le « design thermique » inclut le temps. La capacité thermique signifie qu’un système peut absorber temporairement la chaleur — exactement ce que Tau exploite.
• Les datacenters plafonnent déjà la puissance — les CPU l’ont juste internalisé. Les budgets rack et PDU ont forcé une consommation prévisible ; les limites au niveau CPU en sont l’extension granulaire.

Guide de diagnostic rapide

Quand les performances chutent sous charge, vous voulez identifier rapidement le limiteur. Ne commencez pas par changer les réglages du BIOS.
Commencez par prouver si vous êtes limité par la puissance, par la thermique, ou par autre chose (ordonnanceur, IO, bande passante mémoire).

Première étape : confirmer le schéma des symptômes

• Le débit chute-t-il après une fenêtre temporelle constante (10–60 secondes) ? Pensez à l’application de Tau/PL1.
• Chute-t-elle immédiatement quand la température approche TJmax ? Pensez au throttling thermique / refroidissement.
• Oscille-t-elle en cycles de quelques secondes ? Pensez aux limites VRM/courant, à un PL2 agressif ou au délai de réponse des ventilateurs.

Deuxième étape : capturer puissance + fréquence + drapeaux de throttling ensemble

• Utilisez turbostat (Intel) ou les outils vendeurs pertinents pour capturer : puissance package, MHz, température et raisons de throttling.
• Corrélez avec dmesg pour les messages thermiques/prochot et avec journalctl pour les démons plateformes modifiant les politiques.

Troisième étape : vérifier quelles limites sont configurées et qui les a définies

• Lire les valeurs powercap RAPL depuis sysfs ; comparer aux attentes BIOS.
• Vérifier si un démon constructeur ou un profil d’alimentation réécrit les limites à l’exécution.
• Sur hôtes virtualisés, vérifier si des politiques d’hyperviseur plafonnent la puissance CPU indirectement (par ex., profils d’alimentation, cgroups, gouverneurs cpufreq).

Quatrième étape : décider de la classe de correctif

• Si limité par la puissance mais la thermique est correcte : augmenter PL1 modestement, ou accepter le cap et planifier la capacité en conséquence.
• Si limité thermiquement : réparer le refroidissement d’abord ; augmenter PL1 ne fait que le faire throttler plus sévèrement.
• Si limité par le courant/VRM : réduire PL2 ou améliorer la conception carte mère/PSU ; vous ne pouvez pas « transformer » une distribution d’énergie faible en force par réglage.
• Si pas limité par le CPU : cessez de toucher aux réglages PL et allez chercher le vrai goulot.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les vérifications que j’exécute vraiment quand quelqu’un dit « le CPU se bride ».
Les lignes de commande sont centrées sur Linux parce que la production a tendance à être centrée sur Linux. Adaptez selon votre environnement.

Tâche 1 : Identifier le modèle CPU et les bases de la plateforme

cr0x@server:~$ lscpu | egrep 'Model name|Socket|Thread|Core|CPU\(s\)|MHz'
Model name:                           Intel(R) Xeon(R) CPU E-2288G @ 3.70GHz
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
CPU MHz:                              3700.000

Ce que cela signifie : Vous avez besoin du SKU exact car les valeurs PL par défaut varient selon le SKU, l’OEM et le microcode.
La ligne MHz actuelle n’est généralement pas suffisante pour le diagnostic mais ancre vos attentes.
Décision : Enregistrez le modèle CPU avant de comparer des nœuds ou d’accuser « matériel identique ».

Tâche 2 : Vérifier le comportement de fréquence sous charge

cr0x@server:~$ sudo apt-get -y install stress-ng >/dev/null
cr0x@server:~$ stress-ng --cpu 16 --cpu-method matrixprod --metrics-brief --timeout 30s
stress-ng: info:  [12421] dispatching hogs: 16 cpu
stress-ng: metrc: [12421] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [12421] cpu             39132     30.00   456.18     0.12      1304.40

Ce que cela signifie : Cela crée une charge soutenue contrôlée. Les métriques vous permettent de comparer « avant/après » les changements.
Décision : Exécutez cela en parallèle avec turbostat pour voir si la performance décroît durant l’exécution.

Tâche 3 : Capturer turbo, puissance et drapeaux de throttling avec turbostat

cr0x@server:~$ sudo turbostat --Summary --interval 1 --quiet --num_iterations 10
     time  Avg_MHz  Busy%  Bzy_MHz  PkgWatt  CorWatt  PkgTmp  GFXWatt
     1.00     4680  98.23     4764    124.9     88.2      86     0.0
     2.00     4681  98.10     4766    125.1     88.0      89     0.0
     3.00     4502  98.05     4589    108.0     76.1      92     0.0
     4.00     4100  98.00     4189     95.2     67.5      92     0.0
     5.00     4098  98.02     4188     95.0     67.3      91     0.0

Ce que cela signifie : Vous pouvez littéralement voir la chute : la puissance du package diminue et le MHz tombe après quelques secondes.
C’est cohérent avec l’expiration de Tau et la stabilisation près de PL1.
Décision : Si PkgTmp reste stable en dessous de TJmax mais que le MHz chute avec PkgWatt, vous êtes probablement limité par la puissance (PL1), pas par la thermique.

Tâche 4 : Vérifier les logs du noyau pour événements thermiques et PROCHOT

cr0x@server:~$ sudo dmesg -T | egrep -i 'thermal|thrott|prochot|temperature' | tail -n 8
[Mon Jan 10 09:12:31 2026] thermal thermal_zone0: critical temperature reached (100 C), shutting down
[Mon Jan 10 09:15:02 2026] CPU0: Core temperature above threshold, cpu clock throttled (total events = 42)
[Mon Jan 10 09:15:02 2026] CPU2: Package temperature above threshold, cpu clock throttled (total events = 42)

Ce que cela signifie : C’est la preuve d’un throttling thermique réel. Si vous voyez cela, arrêtez de « tuner PL » et réparez le refroidissement.
Décision : Traitez les événements répétés comme un problème de fiabilité ; le stress thermique réduit la durée de vie et augmente les taux d’erreur.

Tâche 5 : Lire les valeurs limite RAPL depuis sysfs

cr0x@server:~$ ls -1 /sys/class/powercap/intel-rapl
intel-rapl:0
intel-rapl:0:0
intel-rapl:0:1

cr0x@server:~$ cd /sys/class/powercap/intel-rapl/intel-rapl:0
cr0x@server:~$ cat name
package-0
cr0x@server:~$ cat constraint_0_name
long_term
cr0x@server:~$ cat constraint_0_power_limit_uw
95000000
cr0x@server:~$ cat constraint_0_time_window_us
28000000
cr0x@server:~$ cat constraint_1_name
short_term
cr0x@server:~$ cat constraint_1_power_limit_uw
125000000

Ce que cela signifie : La limite long terme est 95W (PL1), la fenêtre temporelle est de 28 secondes (Tau), la limite court terme est 125W (PL2).
Les unités sont des micro-Watts et micro-secondes.
Décision : Si ces valeurs ne correspondent pas à ce que vous attendez du BIOS, quelque chose (firmware, OS, démon) les override.

Tâche 6 : Observer l’énergie package courante et calculer la puissance moyenne

cr0x@server:~$ cat /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
124987654321

Ce que cela signifie : Ce compteur s’incrémente en énergie utilisée (micro-Joules). Échantillonnez-le deux fois avec des timestamps pour calculer la puissance moyenne.
Décision : Utilisez ceci quand vous ne pouvez pas faire confiance aux outils de plus haut niveau, ou pour recouper turbostat.

Tâche 7 : Vérifier qui gère la politique de fréquence CPU (gouverneur)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Ce que cela signifie : Le gouverneur affecte la sélection de fréquence mais n’écrase pas les limites de puissance hard.
Si vous êtes en powersave, vous pouvez vous auto-brider avant même que les limites PL importent.
Décision : Pour des tests de performance cohérents, utilisez performance. Pour une politique de flotte, choisissez intentionnellement.

Tâche 8 : Détecter si intel_pstate est en mode actif et quelles sont les limites

cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/status
active
cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
100
cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/min_perf_pct
20

Ce que cela signifie : Vous utilisez intel_pstate avec la performance maximale autorisée.
Si max_perf_pct est bas, quelqu’un vous a plafonné et vous accuserez injustement PL1.
Décision : Gardez ces valeurs cohérentes entre les nœuds avant de comparer les performances.

Tâche 9 : Vérifier la présence de démons de gestion d’énergie runtime qui changent la politique

cr0x@server:~$ systemctl list-units --type=service | egrep 'tlp|power-profiles-daemon|thermald'
power-profiles-daemon.service loaded active running Power Profiles daemon
thermald.service              loaded active running Thermal Daemon Service

Ce que cela signifie : Ces services peuvent influencer les profils de performance et le comportement thermique. Sur portables et certains serveurs, ils peuvent aussi écrire des limites de puissance.
Décision : Pour des expériences contrôlées, arrêtez-les temporairement (prudemment) ou au moins sachez qu’ils existent.

Tâche 10 : Vérifier si la plateforme expose des raisons de throttling (flags turbostat)

cr0x@server:~$ sudo turbostat --interval 1 --num_iterations 5 | egrep 'PkgWatt|Bzy_MHz|PkgTmp|IRQ|^CPU|PL1|PL2|THERMAL'
CPU     Avg_MHz   Busy%   Bzy_MHz   PkgTmp   PkgWatt
-       4650      97.8    4730      88       124.0
-       4635      97.9    4720      90       124.8
-       4105      98.0    4186      91        95.1

Ce que cela signifie : Certaines versions de turbostat affichent des colonnes explicites de throttling ; d’autres non selon le noyau et le support CPU.
Même sans flags, le couplage entre MHz et PkgWatt est un indice fort.
Décision : Si vous ne voyez pas de flags, compensez avec les limites RAPL sysfs et les logs du noyau.

Tâche 11 : Changer PL1/PL2/Tau (avec précaution) via powercap sysfs

cr0x@server:~$ cd /sys/class/powercap/intel-rapl/intel-rapl:0
cr0x@server:~$ sudo sh -c 'echo 105000000 > constraint_0_power_limit_uw'
cr0x@server:~$ sudo sh -c 'echo 140000000 > constraint_1_power_limit_uw'
cr0x@server:~$ sudo sh -c 'echo 35000000 > constraint_0_time_window_us'
cr0x@server:~$ cat constraint_0_power_limit_uw
105000000
cr0x@server:~$ cat constraint_0_time_window_us
35000000
cr0x@server:~$ cat constraint_1_power_limit_uw
140000000

Ce que cela signifie : Vous avez augmenté PL1 à 105W, PL2 à 140W, Tau à 35s. Cela peut ou non persister après reboot.
Décision : Ne faites cela que sur un nœud de test d’abord. Puis relancez la même charge + capture turbostat et comparez.

Tâche 12 : Valider l’effet réel du changement avec un benchmark reproductible

cr0x@server:~$ stress-ng --cpu 16 --cpu-method matrixprod --metrics-brief --timeout 60s
stress-ng: info:  [13200] dispatching hogs: 16 cpu
stress-ng: metrc: [13200] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [13200] cpu             85510     60.00   909.90     0.12      1425.17

Ce que cela signifie : Si le bogo ops/s s’améliore et reste stable pendant l’exécution, votre nouvel état stable est meilleur.
Si cela s’améliore au départ mais régresse ensuite, vous avez probablement poussé dans des limites thermiques ou de courant.
Décision : Ne conservez le changement que s’il améliore le débit soutenu sans augmenter les événements de throttling ou les logs d’erreur.

Tâche 13 : Vérifier les capteurs de température réels et le comportement des ventilateurs

cr0x@server:~$ sudo apt-get -y install lm-sensors >/dev/null
cr0x@server:~$ sudo sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +92.0°C  (high = +95.0°C, crit = +100.0°C)
Core 0:        +90.0°C  (high = +95.0°C, crit = +100.0°C)
Core 1:        +91.0°C  (high = +95.0°C, crit = +100.0°C)

Ce que cela signifie : Vous êtes proche des seuils high/crit. Même si vous êtes « seulement » limité par la puissance maintenant, vous n’avez pas de marge thermique.
Décision : N’augmentez pas les limites PL sur une machine qui vit à 92°C sous charge routinière. Réparez le flux d’air, les courbes de ventilateurs, la poussière ou le montage du radiateur d’abord.

Tâche 14 : Vérifier si les cgroups plafonnent le CPU (commun dans les conteneurs)

cr0x@server:~$ cat /sys/fs/cgroup/cpu.max 2>/dev/null || true
80000 100000

Ce que cela signifie : Cela indique que le cgroup peut utiliser 80% d’un CPU par période de 100ms (cgroup v2). C’est un plafond artificiel.
Décision : Si vous voyez cela, votre « throttling » peut être l’ordonnancement cgroup, pas PL1/PL2. Corrigez les limites d’orchestration avant de régler la puissance.

Tâche 15 : Repérer un décalage BIOS/firmware entre nœuds

cr0x@server:~$ sudo dmidecode -t bios | egrep 'Vendor|Version|Release Date'
Vendor: American Megatrends International, LLC.
Version: 2.1.7
Release Date: 08/14/2024

Ce que cela signifie : Les différences de version BIOS impliquent souvent des comportements PL/Tau par défaut différents.
Décision : Dans une flotte, standardisez les versions BIOS (et les réglages) avant d’entamer une médecine légale de performance.

Trois mini-récits d’entreprise sur le terrain

1) L’incident causé par une mauvaise hypothèse : « TDP égale performance »

Une entreprise SaaS de taille moyenne a déployé une nouvelle série de serveurs « même CPU, même RAM » pour un service sensible à la latence.
Ils remplaçaient des hôtes plus anciens devenus limités en capacité, donc les attentes étaient simples : même SKU, simplement des machines plus récentes, devraient être égales ou meilleures.

La première semaine était correcte en préproduction. Puis la production a observé un schéma étrange : matinées excellentes, après-midis catastrophiques.
La latence p95 montait pendant le plateau de trafic quotidien, mais l’utilisation CPU semblait normale.
La première réaction fut classique : « ce doit être le garbage collection » (ce n’était pas), puis « ce doit être le réseau » (non plus).

Un SRE a finalement tracé le débit par hôte dans le temps pour un test de charge synthétique et a remarqué une chute constante après ~30 secondes.
C’était le signal. Les anciens serveurs avaient une configuration turbo prudente : PL2 modeste, Tau sensé, état stable stable.
Les nouveaux serveurs étaient livrés avec un profil OEM « performance » : PL2 élevé et un Tau suffisamment long pour imbiber thermiquement le châssis,
et un PL1 qui était en fait inférieur à l’attendu une fois que le contrôleur embarqué a commencé à protéger la thermique de la plateforme.

L’erreur n’était pas « le turbo est mauvais ». L’erreur était de supposer « TDP est une propriété du CPU, donc le comportement doit correspondre ».
En pratique, le firmware plateforme, le VRM et le refroidissement définissent le véritable état stable. Le même CPU dans deux châssis n’est pas le même produit.

Ils ont résolu le problème en standardisant les réglages BIOS entre fournisseurs : valeurs PL1/PL2/Tau explicites testées contre leur charge réelle.
La latence s’est stabilisée. La consommation est devenue prévisible. Les achats ont appris une nouvelle règle : « Même SKU » n’est pas un test d’acceptation.

2) L’optimisation qui a mal tourné : « Augmenter PL2 pour des déploiements plus rapides »

Une grande entreprise avait une flotte CI où les temps de compilation et de test augmentaient. Quelqu’un a proposé une solution séduisante :
« Ces CPU supportent une puissance turbo plus élevée. Augmentons PL2 et Tau pour que les builds finissent plus vite. »
Cela a fonctionné dans un sens étroit. Le temps médian de build s’est amélioré. Les graphiques en réunion étaient jolis.

Deux semaines plus tard, la flotte a commencé à voir des échecs intermittents : redémarrages aléatoires de workers, checks machine kernel occasionnels,
et le type de comportement instable qui fait blâmer « les rayons cosmiques » puis changer discrètement de sujet.
Les diagnostics matériels n’ont rien trouvé d’évident. Les températures n’étaient même pas alarmantes — juste en pics.

Le vrai problème était les transitoires. Augmenter PL2 et Tau a provoqué des pics de courant répétés pendant les builds parallèles.
Le VRM et la combinaison PSU de ce châssis particulier pouvaient gérer la charge moyenne mais détestaient les rafales répétées à puissance élevée.
Le système restait « dans les limites thermiques » tout en stressant les composants de distribution d’énergie.
Les pannes se concentraient pendant les périodes de forte concurrence de build où les motifs de rafales s’alignaient.

Le retour arrière a éliminé les redémarrages. Ils ont ensuite réintroduit une version plus sûre : augmentation modeste de PL2 avec Tau plus serré,
plus un plafond de concurrence par hôte pour lisser les motifs de charge. Le temps médian de build a un peu empiré par rapport au pic irréfléchi,
mais le taux de panne est redevenu normal, ce qui est le seul KPI qui compte quand le pager sonne.

La morale : augmenter PL2 n’est pas gratuit. Cela déplace la contrainte de « chaleur dans le temps » vers « courant maintenant ». Le courant immédiat révèle les maillons faibles.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : « limites explicites et détection de dérive »

Une fintech exploitait une flotte mixte : certains nœuds étaient neufs, d’autres anciens, certains dans un datacenter, d’autres ailleurs.
Ils avaient des exigences de performance strictes pendant les heures de marché et des budgets d’alimentation stricts dans une installation déjà proche des limites PDU.
Tout le monde voulait « la performance maximale », mais personne ne voulait un incident d’alimentation pendant le trading.

Ils ont fait la chose ennuyeuse. Ils ont créé un document de profil matériel par plateforme listant explicitement PL1/PL2/Tau,
les réglages BIOS, les profils de ventilateurs et les paramètres du gouverneur OS. Ils l’ont appliqué via la gestion de configuration qui validait les valeurs RAPL au démarrage,
et ils ont alerté sur la dérive si un nœud rapportait des contraintes différentes de celles attendues.

Des mois plus tard, une mise à jour microcode/BIOS urgente est passée pour des raisons de sécurité. Après la mise à jour, un sous-ensemble de nœuds a changé silencieusement
leur comportement par défaut Tau et PL2. Sans détection de dérive, l’équipe ne l’aurait remarqué que lorsque la latence en queue aurait commencé à s’élargir.
Au lieu de cela, des alertes ont déclenché dans l’heure suivant le premier redémarrage canari.

Ils ont corrigé la déviation de profil en réappliquant les valeurs explicites et ont continué. Pas d’incident. Pas de graphique mystère.
Juste le type de compétence ingrate qui vous garde employé.

Erreurs courantes (symptômes → cause → correctif)

1) « Ça booste à 5 GHz puis retombe à 3,8 GHz »

Symptômes : Baisse répétable après une fenêtre temporelle fixe ; températures pas à TJmax.

Cause : Tau expire et le CPU se stabilise à l’état PL1.

Correctif : Décidez si vous avez besoin de performance soutenue (augmenter PL1 si le refroidissement le permet) ou acceptez PL1 et planifiez la capacité. Évitez « augmentez juste Tau » sauf si la charge se termine réellement dans cette fenêtre étendue.

2) « Les températures sont correctes mais la performance est faible »

Symptômes : MHz bas sous charge, puissance package faible, pas de logs thermiques.

Cause : Plafond de politique OS (intel_pstate max_perf_pct, gouverneur cpufreq), quotas CPU cgroup, ou profil d’alimentation hyperviseur.

Correctif : Vérifiez le gouverneur, les caps intel_pstate et les quotas cgroup avant de toucher aux limites PL.

3) « Nous avons augmenté PL1 et obtenu de pire performances »

Symptômes : Puissance initiale plus élevée, puis throttling plus marqué ; événements thermiques supplémentaires ; ventilateurs à fond.

Cause : Vous êtes passé d’un état limité par la puissance à un état limité thermiquement (TJmax/PROCHOT).

Correctif : Améliorez le refroidissement (assise du heatsink, flux d’air, courbe de ventilateurs, ambient). Puis réévaluez PL1. Si vous ne pouvez pas refroidir, ne l’alimentez pas.

4) « Redémarrages aléatoires après tuning du turbo »

Symptômes : Instabilité sous charges parallèles en rafales ; pas de shutdown thermique clair ; erreurs matérielles sporadiques.

Cause : Stress transitoire VRM/PSU/courant dû à un PL2/Tau agressif ; limites de distribution d’énergie plateforme.

Correctif : Réduire PL2 et/ou Tau ; lisser la concurrence de charge ; vérifier PSU/VRM et BIOS pour ce profil de puissance.

5) « Deux serveurs identiques ont des performances différentes »

Symptômes : Même SKU CPU, MHz et puissance soutenus différents ; résultats de bench incohérents.

Cause : Versions BIOS différentes, profils par défaut du fournisseur, ou refroidissement/VRM différent du châssis.

Correctif : Standardisez la configuration BIOS ; relisez les contraintes RAPL ; considérez « même SKU » comme insuffisant.

6) « Nous réglons les limites dans l’OS mais elles reviennent »

Symptômes : Les valeurs sysfs changent après reboot ou après le démarrage d’un démon.

Cause : Le BIOS réaffirme les limites au démarrage, ou un démon de gestion d’énergie les réécrit à l’exécution.

Correctif : Préférez le BIOS pour des valeurs par défaut stables dans la flotte ; si vous utilisez le contrôle OS, appliquez au démarrage via une unité systemd et désactivez les services conflictuels.

7) « La performance du portable chute sur batterie »

Symptômes : PL1/PL2 beaucoup plus bas sur batterie ; throttling marqué sous charge soutenue.

Cause : Le contrôleur embarqué applique les budgets batterie/adaptateur et les contraintes de température de coque.

Correctif : Utilisez un profil d’alimentation approprié ; ne faites pas de benchs sur batterie ; acceptez que la plateforme, pas le CPU, décide.

Listes de contrôle / plan étape par étape

Étape par étape : établir une base de référence fiable

1. Enregistrer l’identité de la plateforme : modèle CPU (lscpu), version BIOS (dmidecode), version du noyau, version du microcode.
2. Enregistrer la politique : gouverneur (scaling_governor), statut intel_pstate, démons d’énergie en cours.
3. Enregistrer les limites configurées : lire les contraintes RAPL (PL1/PL2/Tau) depuis sysfs.
4. Exécuter une charge contrôlée : par ex., stress-ng pendant 60s.
5. Capturer la télémétrie : turbostat intervalle 1s, plus la sortie sensors près de l’état stable.
6. Annoter le temps jusqu’à la falaise : moment où fréquence/puissance chutent ; comparer à Tau.

Étape par étape : décider de changer les limites

1. Si la température est proche de TJmax : n’augmentez pas PL1/PL2. Réparez le refroidissement d’abord.
2. Si PkgWatt se bloque près de PL1 et que la température est sûre : envisagez d’augmenter PL1 par petits incréments (5–10W) et retestez.
3. Si vous n’avez besoin que de courtes rafales : ajustez PL2 et Tau pour correspondre à la durée des rafales, pas pour gagner des graphiques synthétiques.
4. Si la stabilité prime sur le pic : baissez PL2 et/ou Tau pour réduire oscillation et pics de courant.
5. Validez avec une charge proche de la production : pas seulement un burn CPU synthétique ; incluez mémoire et IO.

Checklist flotte : éviter que ça redevienne un mystère récurrent

• Définir PL1/PL2/Tau explicites dans le BIOS pour chaque classe matérielle.
• Conserver les « contraintes RAPL attendues » et les vérifier au démarrage.
• Alerter sur la dérive : si les contraintes changent, traiter comme une dérive de configuration.
• Maintenir des versions BIOS cohérentes, surtout après des mises à jour de sécurité.
• Planifier la capacité en utilisant la performance d’état stable (PL1), pas la rafale (PL2).
• Documenter la règle métier : optimisez-vous pour la latence des rafales ou pour le débit soutenu ?

FAQ

1) PL1 et TDP sont-ils la même chose ?

Pas de manière fiable. Beaucoup de plateformes règlent PL1 près du TDP, mais les OEM peuvent le fixer plus haut ou plus bas selon le refroidissement et les objectifs produit.
Traitez le TDP comme une cible marketing thermique, pas comme une garantie de comportement de puissance soutenu.

2) Pourquoi je vois d’excellents chiffres de bench mais une mauvaise performance soutenue ?

Parce que les benchs vivent souvent dans la fenêtre PL2/Tau. Ils mesurent le sprint. Votre charge est un marathon.
Mesurez à l’état stable et surveillez le temps jusqu’au clamp.

3) Si les températures sont basses, puis-je augmenter PL1 en toute sécurité ?

« En toute sécurité » dépend du VRM, du PSU et du flux d’air du châssis, pas seulement de la température CPU.
Une température basse suggère une marge thermique, mais vous devez toujours valider la stabilité et la distribution d’énergie sous charge en rafales et soutenue.

4) Quelle est une valeur Tau raisonnable ?

Cela dépend de la charge. Si votre service subit des rafales de quelques secondes, un Tau long ajoute surtout de la chaleur et du risque d’oscillation.
Si vos tâches finissent en 20–40 secondes, régler Tau peut être pertinent. Pour les jobs longue durée, Tau affecte surtout la première minute puis PL1 domine.

5) Pourquoi augmenter PL2 réduit parfois la performance ?

Parce que cela peut déclencher des transitoires thermiques ou des limites de courant, entraînant un throttling plus agressif ensuite.
Vous obtenez un départ plus chaud et un atterrissage pire. La performance devient en dents de scie plutôt que plate.

6) Puis-je régler les limites PL dans une VM ou un conteneur ?

Généralement pas de manière significative. Les limites PL sont appliquées au niveau hôte CPU/package.
Dans les conteneurs vous pouvez plafonner le CPU via les cgroups ; dans les VM vous pouvez modeler l’ordonnancement des vCPU, mais vous ne pouvez généralement pas réécrire les contraintes RAPL de l’hôte.

7) Quelle est la différence de symptômes entre throttling par puissance et throttling thermique ?

Le throttling par puissance montre souvent une chute de fréquence alors que la température reste en dessous de TJmax et la puissance du package se bloque près d’une limite.
Le throttling thermique montre la température atteignant un plafond et des logs ou flags indiquant des événements thermiques ; la puissance peut chuter en conséquence.

8) Dois-je toujours définir des profils « performance maximale » dans le BIOS ?

Pas aveuglément. « Performance maximale » signifie souvent PL2 plus élevé et Tau plus long, ce qui peut violer votre budget d’alimentation rack et nuire à la prévisibilité.
Pour la production, choisissez « performance cohérente » sauf si vous avez une raison mesurée de courir après les pics.

9) Les systèmes AMD ont-ils les mêmes concepts PL1/PL2/Tau ?

Les noms diffèrent, mais l’idée — budgets de puissance sur des fenêtres temporelles — est commune aux CPU modernes.
Sur AMD vous verrez d’autres contrôles (PPT/TDC/EDC et comportements de boost), mais vous diagnostiquez de la même manière : corréler horloges, puissance, température et flags de limite.

10) Quel est le graphe le plus utile pour ça ?

Fréquence, puissance package et température sur la même timeline pendant un test de charge soutenu, avec les flags de throttling/limite si disponibles.
La « falaise » devient évidente et vous pouvez la faire correspondre à Tau ou aux plafonds thermiques.

Prochaines étapes que vous pouvez vraiment faire

PL1, PL2 et Tau ne sont pas des trivia. Ce sont des politiques. La politique contrôle la performance, la thermique, la stabilité et les budgets d’alimentation.
Si vous les traitez comme des nombres magiques, vous aurez des problèmes magiques : débits incohérents, falaises mystérieuses et serveurs « identiques » qui ne le sont pas.

Faites ceci ensuite :

1. Choisissez un nœud représentatif et capturez un test de charge de 60 secondes avec turbostat + sensors.
2. Relisez les PL1/PL2/Tau configurés depuis RAPL sysfs et comparez au comportement observé.
3. Décidez ce que vous optimisez : latence de rafale ou débit soutenu. Écrivez-le.
4. Changez une variable à la fois (PL1 ou PL2 ou Tau), par petits incréments, et retestez sous la même charge.
5. Standardisez les réglages BIOS dans la flotte et alertez sur la dérive pour ne pas redécouvrir ce problème chaque trimestre.

Les systèmes prévisibles sont souvent un peu moins excitants. C’est le but.