Turbo Boost : comment les CPU trichent sur leurs fiches techniques (légalement)

Fiches techniques vs réalité : ce que « turbo » promet réellement

Le marketing CPU veut que vous pensiez en un seul nombre : « jusqu’à 5,0 GHz ». Les opérations veulent un autre chiffre : « quelle fréquence j’obtiens toute la journée sous ma charge réelle, avec mon refroidissement, mes limites d’alimentation et la VM bruyante du voisin ? » Turbo Boost est l’endroit où ces deux chiffres cessent d’être amis.

La fréquence de base est le contrat ennuyeux ; le turbo est un coupon conditionnel

La fréquence de base est le chiffre « je peux faire ça durablement » du CPU sous une enveloppe de puissance définie. Le turbo est un surplus opportuniste. Il utilise la marge de puissance et thermique non utilisée pour augmenter la fréquence — souvent de manière agressive — pour de petites fenêtres et parfois plus longtemps, selon les paramètres de la plateforme.

Ce « jusqu’à » fréquence turbo n’est pas « ce que vous verrez ». C’est « ce que vous pourriez voir sur un (ou quelques) cœurs, pour une certaine durée, si la puissance et la température le permettent, et si le firmware est d’humeur généreuse ». Dans les serveurs, c’est généralement conservateur sauf si le fournisseur l’a configuré pour chasser des benchmarks.

Turbo n’est pas juste une fréquence ; c’est tout un système de contrôle

Les CPU modernes équilibrent constamment :

• Puissance (watts du package, et parfois puissance par domaine)
• Température (température de jonction et points chauds)
• Limites de courant (contraintes électriques sur les VRM et la livraison au socket)
• Type de charge (AVX/AVX2/AVX-512 peut déclencher des offsets de fréquence)
• Nombre de cœurs (turbo sur 1 cœur ≠ turbo sur tous les cœurs)
• Temps (puissance « sprint » courte vs puissance « marathon » soutenue)

Turbo est une « triche légale » parce que le CPU suit ses règles. C’est vous qui supposez que ces règles correspondent au titre accrocheur.

Blague #1 : Turbo Boost, c’est comme les forfaits mobiles « illimités » : techniquement vrai jusqu’à ce que vous essayiez de l’utiliser.

Pourquoi le turbo existe : la physique et le business

À un niveau élevé, le turbo existe parce que les puces présentent des variations, les charges varient énormément et les datacenters ne fonctionnent pas toujours à la limite thermique du pire cas. Si le CPU peut tourner plus vite sans violer les limites, il le fera — parce que la performance se vend.

Variabilité du silicium et binning

Même au sein d’un même SKU, les puces varient. Certaines nécessitent plus de tension pour une fréquence donnée ; d’autres moins. Les fabricants « binent » les CPU en gammes produits, mais il reste une dispersion. Les mécanismes turbo permettent à une puce d’exploiter dynamiquement sa marge, plutôt que d’imposer une fréquence conservatrice qui conviendrait au pire cas.

Les charges ne sont pas constantes

Une couche web a souvent du trafic en rafales. Une base de données a des pics et des creux. Un travail par lots a des phases (analyse, tri, compression, écriture). Le turbo aide sur les parties en pics sans vous obliger à acheter une gamme supérieure entière pour le 99e percentile de la demande.

Les budgets d’énergie sont de vrais budgets

Dans une armoire, vous pouvez avoir une limite stricte de circuit. Chez un hébergeur cloud, il peut y avoir des plafonds au niveau plateforme pour éviter de déclencher des disjoncteurs. Le turbo transforme cela en jeu : emprunter de la puissance maintenant, rembourser plus tard en baissant la fréquence. Si vous ne regardez que l’utilisation CPU moyenne, vous ratez l’emprunt et le remboursement — pourtant la latence le ressent immédiatement.

Le règlement : puissance, thermique et les minuteries invisibles

Pour faire fonctionner le turbo de façon raisonnable, vous devez connaître les trois réglages qui réapparaissent encore et encore (les noms varient selon le fournisseur, mais le concept est stable) :

• Limite de puissance soutenue (à la manière de Intel PL1) : ce que vous pouvez faire indéfiniment
• Limite de puissance court terme (à la manière de Intel PL2) : ce que vous pouvez faire brièvement
• Fenêtre temporelle (à la manière de Tau) : combien de temps « brièvement » dure

PL1 / PL2 / Tau : le schéma « sprint puis stabilisation »

Beaucoup de systèmes se comportent ainsi : ils vont dépasser la puissance soutenue pendant une fenêtre, puis se stabiliser pour rester dans l’enveloppe à long terme. C’est pourquoi les 30 premières secondes d’un benchmark semblent incroyables et les 10 minutes suivantes donnent l’impression d’avoir acheté le CPU moins cher.

Sur certains serveurs, le firmware vous permet de configurer ces paramètres. Sur d’autres, le fournisseur les verrouille. Quoi qu’il en soit, vous pouvez généralement les observer via des outils et compteurs.

Les limites thermiques priment sur tout

Si votre refroidissement est insuffisant — mauvais flux d’air, filtres bouchés, dissipateurs incompatibles, air d’entrée trop chaud — le turbo devient une promesse en l’air. Le CPU peut atteindre des fréquences élevées brièvement, puis subir du thermal throttle et osciller. Cette oscillation est mortelle pour les services sensibles à la latence car elle crée des pauses périodiques qui se reflètent parfaitement dans vos graphiques p99.

Pénalités liées aux jeux d’instructions : la taxe AVX

Les instructions vectorielles larges consomment plus de puissance et génèrent plus de chaleur. Beaucoup de CPU appliquent des offsets de fréquence lorsque AVX/AVX2/AVX-512 est actif. Ce n’est pas un bug ; c’est un instinct de survie géré via des registres MSR.

Si un service utilise intensivement des opérations vectorisées (crypto/compression) et partage un hôte avec votre service « régulier », la fréquence effective de l’hôte peut baisser de façons qui semblent irrationnelles — jusqu’à ce que vous réalisiez que le CPU se protège d’un pic de puissance.

Firmware et politique plateforme : la question « qui commande ? »

Le comportement du turbo est façonné par une pile :

• Microcode du CPU
• Paramètres BIOS/UEFI (limites de puissance, activation du turbo, bias énergie/performance)
• Gouverneur CPUfreq de l’OS (Linux : performance/ondemand/schedutil)
• Politiques de l’hyperviseur et ordonnancement vCPU (dans les environnements virtualisés)
• Plafond d’alimentation au niveau datacenter (BMC, PDU de rack, gestionnaire de puissance de cluster)

Si vous ne réglez qu’un seul niveau, les autres niveaux peuvent vous ignorer poliment.

Une citation de fiabilité à garder au mur : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Ce que vous observez en production : les motifs courants du turbo

Motif 1 : grand turbo mono‑cœur, médiocre sur tous les cœurs

Excellent pour le travail faiblement threadé : parsing de requêtes, threads UI, certaines étapes de build JavaScript, un shard chaud unique. Décevant pour les charges parallèles : analytics, orages de compaction, reconstructions, chiffrement à grande échelle.

Impact décisionnel : ne planifiez pas la capacité d’une charge parallèle en utilisant le nombre « turbo max ». Utilisez le comportement soutenu all‑core selon votre mix d’instructions.

Motif 2 : rapide pendant 20–60 secondes, puis « pourquoi c’est plus lent qu’il y a une semaine ? »

C’est le comportement classique des fenêtres de puissance. C’est bien pour les rafales interactives et horrible pour les jobs longue durée que vous pensiez maintenir à la vitesse sprint.

Impact décisionnel : pour les jobs par lots, mesurez l’état stable après la fenêtre. Pour les services, mesurez la latence tail sous trafic soutenu, pas le démarrage à froid.

Motif 3 : oscillation de fréquence sous contrainte thermique

Le thermal throttling ressemble souvent à :

• Température du package CPU collée au maximum
• Fréquence qui rebondit (ex. 3.6 → 2.4 → 3.1 → 2.2 GHz)
• Pics de latence corrélés aux baisses

Impact décisionnel : réparez le refroidissement en priorité. Vous ne pouvez pas « logicieliser » la physique. Vous ne pouvez que choisir quelle partie échoue.

Motif 4 : « Mon CPU est à 100 % mais c’est lent » (ce n’est pas que l’utilisation)

L’utilisation ne vous dit pas le travail effectué par cycle, et elle ne vous dit pas le taux de cycles. Un cœur à 100 % à 2,0 GHz n’est pas équivalent à un cœur à 100 % à 3,5 GHz. Ajoutez des variations d’IPC dues aux ratés de cache et vous avez une douleur en trois dimensions.

Impact décisionnel : associez toujours l’utilisation à la fréquence et aux compteurs de throttling. Sinon vous déboguez les yeux fermés.

Faits intéressants & contexte historique (court et concret)

1. La mise à l’échelle dynamique de la fréquence précède la marque « Turbo Boost » : les CPU et portables utilisaient déjà le speed stepping et des états de puissance bien avant l’ère moderne du turbo.
2. Les premiers comportements turbo dépendaient beaucoup du fournisseur et de la carte mère : les BIOS de cartes mères faisaient parfois tourner les CPU au‑delà des limites nominales pour gagner des benchmarks.
3. « Jusqu’à » turbo est généralement un pic par cœur, pas une promesse tous cœurs ; beaucoup de CPU publient des tables turbo séparées selon le nombre de cœurs actifs.
4. Les plateformes serveurs imposent souvent des limites plus strictes que les desktops pour protéger les budgets d’énergie en rack et la fiabilité à long terme.
5. Les instructions vectorielles peuvent déclencher des offsets de fréquence car elles augmentent la densité de puissance ; c’est une des raisons pour lesquelles deux charges « liées au CPU » peuvent obtenir des fréquences très différentes.
6. Les interfaces RAPL d’Intel ont rendu la puissance observable par l’OS, permettant à des outils en espace utilisateur (comme turbostat) de rapporter énergie et puissance de façon pratique.
7. Le Thermal Design Power (TDP) n’est pas la « puissance max » ; c’est une cible de conception liée aux hypothèses de refroidissement soutenu, et le turbo peut la dépasser.
8. Les fournisseurs cloud virtualisent souvent les attentes de performance : le même nombre de vCPU peut correspondre à des fréquences réelles différentes selon la charge de l’hôte et les plafonds de puissance.

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

Mini-récit n°1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a déployé un nouveau service d’ingestion. Le prototype tournait sur quelques serveurs haut de gamme et semblait excellent. L’équipe a fait ce que font les équipes : elle a choisi un SKU CPU basé sur une ligne unique de la fiche du fournisseur — « Max Turbo Frequency » — puis a industrialisé.

En production, le service chauffait, au sens propre. Le pipeline d’ingestion mélangeait parsing, compression et chiffrement. Les CPU hôtes atteignaient des horloges élevées pendant un court instant puis retombaient vers une fréquence soutenue beaucoup plus basse. Le service était encore « CPU 85 % », mais le débit chutait et les files d’attente s’allongeaient jusqu’à ce que des systèmes en aval commencent à timeout.

L’équipe d’astreinte a chassé les suspects habituels : réseau, stockage, GC. Rien d’évident. Puis quelqu’un a comparé les chiffres du benchmark au démarrage avec une exécution soutenue de 30 minutes et a vu la courbe : démarrage rapide, stabilisation lente. Ce n’était pas une régression logicielle ; c’était un comportement de fenêtre de puissance plus un mix d’instructions qui déclenchait des offsets de fréquence.

La correction n’a rien d’héroïque. Ils ont refait la planification de capacité en utilisant des mesures soutenues all‑core sous la charge réelle, ajusté les profils BIOS performance/puissance, et choisi un SKU légèrement différent avec un meilleur comportement soutenu. Ils ont aussi mis à jour les runbooks : « la fréquence turbo n’est pas un chiffre de capacité. » L’incident s’est terminé sur une ligne ennuyeuse du postmortem : mauvaise hypothèse, résultat prévisible.

Mini-récit n°2 : L’optimisation qui a mal tourné

Une équipe plateforme interne voulait réduire la latence pour un ensemble de services API. Quelqu’un a proposé d’épingler les threads sur des cœurs spécifiques et de désactiver la variabilité de fréquence en forçant le gouverneur Linux sur performance. Sensé sur le papier, et cela a amélioré la latence médiane lors d’un test rapide.

Deux semaines plus tard, la latence empirait aux heures de pointe. Les serveurs tournaient près de leur limite thermique parce que le gouverneur « performance » gardait les fréquences élevées même quand la charge n’en avait pas besoin. Les ventilateurs montaient en régime, les températures d’entrée augmentaient, et les CPU ont commencé à thermal throttle. Résultat : horloges oscillantes, latence tail pire, et l’effet voisin bruyant habituel qui fait que chaque équipe accuse toutes les autres.

L’équipe a finalement appris à la dure : épingler + fréquence toujours haute réduit la marge thermique. Ils sont revenus sur le changement généralisé du gouverneur, ont affiné les limites de puissance par hôte, et ajouté des compteurs de température et de throttling à leurs tableaux de bord SLO. La médiane semblait un poil pire que la configuration « optimisée », mais le p99 a cessé de se comporter comme un sismographe.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise de services financiers exploitait une large flotte de serveurs de bases de données. Rien d’exotique : réglages BIOS prudents, profils de puissance conservateurs et contrôle de changement strict. Ils avaient aussi une habitude qui paraissait terne jusqu’à ce qu’elle compte : chaque SKU matériel passait par un test standardisé de « caractérisation en charge soutenue » avant d’être approuvé pour la production.

Un nouveau rack est arrivé avec une révision de carte mère légèrement différente. Même SKU CPU, même RAM, mêmes disques. Les chiffres de benchmark à la première minute étaient excellents. Sur une heure, la fréquence soutenue all‑core était plus basse que la baseline approuvée. L’équipe a signalé et mis en pause le déploiement.

Il s’est avéré que le fournisseur avait expédié une politique de puissance par défaut différente dans le firmware — boost court plus agressif, limite soutenue plus basse. Les serveurs allaient bien pour des benchmarks courts et moins bien pour des bases de données qui ne s’arrêtent pas après 56 secondes.

Parce que l’équipe avait un test ennuyeux et une porte d’entrée ennuyeuse, ils n’ont pas découvert cela pendant une ouverture de marché. Ils l’ont découvert en staging, avec du café et un ticket. Ils ont ajusté les limites de puissance BIOS pour correspondre à la baseline puis ont mis le matériel en service. Personne n’a été pagé, ce qui est le meilleur type de succès.

Tâches pratiques : commandes, sorties, signification et décision

Ces commandes sont orientées Linux parce que c’est là que résident la plupart des outils d’observabilité. Exécutez‑les sur du bare metal si possible. Sur des VM, vous pouvez obtenir une vérité partielle, ce qui est aussi une leçon.

Tâche 1 : Identifier le modèle CPU et la fréquence base/max annoncée

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|MHz'
Model name:                           Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz
CPU(s):                               80
Thread(s) per core:                   2
Core(s) per socket:                   20
Socket(s):                            2
CPU MHz:                              2100.000

Ce que cela signifie : La chaîne modèle contient la fréquence de base (2.10 GHz ici). La ligne CPU MHz est un instantané et n’indique pas le turbo ; elle est souvent trompeuse.

Décision : Enregistrez le SKU et la topologie des cœurs. Cessez de citer « jusqu’à » turbo comme base ; traitez‑le comme un plafond conditionnel.

Tâche 2 : Vérifier la politique du gouverneur CPUfreq courant

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

Ce que cela signifie : L’OS est autorisé à mettre à l’échelle la fréquence en fonction des heuristiques de l’ordonnanceur. Si vous voyez powersave, attendez‑vous à des horloges conservatrices ; si vous voyez performance, attendez des fréquences soutenues plus élevées (et plus de chaleur).

Décision : Pour les services sensibles à la latence, préférez un comportement prévisible : soit performance avec marge thermique, soit schedutil avec vérification du p99. Ne changez pas cela aveuglément sur toute la flotte.

Tâche 3 : Voir les limites min/max de fréquence exposées à l’OS

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
800000
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
3900000

Ce que cela signifie : Ce sont des kHz. Le max peut représenter un plafond turbo, mais il ne garantit pas que vous l’atteindrez.

Décision : Si le max est anormalement bas, vérifiez les paramètres BIOS, les plafonds de puissance ou les contraintes de virtualisation.

Tâche 4 : Observer le turbo réel et le throttling avec turbostat (Intel)

cr0x@server:~$ sudo turbostat --Summary --interval 5 --quiet
CPU     Avg_MHz   Busy%   Bzy_MHz  IPC  PkgWatt  CorWatt  PkgTmp
-       2875      62.10   4628     1.45  178.32   142.10   83

Ce que cela signifie : Bzy_MHz est le MHz effectif lorsque le CPU est occupé (plus proche de ce qui vous importe). PkgWatt et PkgTmp montrent si vous êtes limité en puissance ou thermiquement.

Décision : Si PkgTmp est proche du maximum et que le MHz chute, réparez le refroidissement. Si les watts sont plafonnés et la fréquence basse, enquêtez sur les limites de puissance.

Tâche 5 : Surveiller la fréquence sous charge soutenue (rapide et sale)

cr0x@server:~$ grep -n "cpu MHz" /proc/cpuinfo | head
1:cpu MHz         : 3799.812
29:cpu MHz        : 3810.224
57:cpu MHz        : 2201.104

Ce que cela signifie : Instantanés par cœur. Des valeurs mixtes peuvent indiquer un ordonnancement inégal, des gradients thermiques ou des décisions de gestion d’énergie.

Décision : Utilisez‑le pour un test rapide d’odeur, pas pour une conclusion. Si cela semble étrange, confirmez avec turbostat.

Tâche 6 : Vérifier les indicateurs d’activation/désactivation du turbo (Intel pstate)

cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/no_turbo
0

Ce que cela signifie : 0 signifie que le turbo est autorisé ; 1 signifie que le turbo est désactivé.

Décision : Si vous déboguez « pourquoi ça ne turbo pas », c’est un contrôle de première classe. Si vous désactivez le turbo pour la prévisibilité, documentez‑le et re‑testez la capacité.

Tâche 7 : Inspecter les limites de puissance plateforme via RAPL (Intel)

cr0x@server:~$ sudo powercap-info --intel-rapl
Zone: package-0
  power limit 1: 165.00 W (enabled)  time window: 28.00 s
  power limit 2: 210.00 W (enabled)  time window: 0.00 s
Zone: package-1
  power limit 1: 165.00 W (enabled)  time window: 28.00 s
  power limit 2: 210.00 W (enabled)  time window: 0.00 s

Ce que cela signifie : C’est le tableau pratique PL1/PL2 : limites soutenue et court‑terme. Si PL1 est bas, vos horloges soutenues seront basses.

Décision : Si cela ne correspond pas à vos attentes ou au profil fournisseur, alignez les paramètres BIOS avec vos objectifs performance/SLO.

Tâche 8 : Détecter le thermal throttling dans les logs du kernel

cr0x@server:~$ sudo dmesg | egrep -i 'thrott|thermal|power limit' | tail -n 5
[12345.678901] CPU0: Package temperature above threshold, cpu clock throttled
[12345.678950] CPU0: Core temperature above threshold, cpu clock throttled

Ce que cela signifie : Le kernel vous indique que le CPU a atteint des limites thermiques.

Décision : Ne touchez pas le logiciel en premier. Vérifiez les dissipateurs, le flux d’air, les courbes de ventilateurs, les températures d’entrée et les panneaux de remplissage de rack.

Tâche 9 : Lire les capteurs de température CPU (lm-sensors)

cr0x@server:~$ sensors | egrep 'Package id 0|Package id 1'
Package id 0:  +84.0°C  (high = +90.0°C, crit = +100.0°C)
Package id 1:  +82.0°C  (high = +90.0°C, crit = +100.0°C)

Ce que cela signifie : Vous êtes proche du seuil « high » ; la marge turbo diminue.

Décision : Si vous tournez régulièrement près de high en charge normale, traitez‑le comme un problème de capacité de refroidissement, pas comme une anomalie.

Tâche 10 : Voir si vous avez un comportement lié à AVX (preuve indirecte)

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,msr/aperf/,msr/mperf/ -- sleep 10
 Performance counter stats for 'system wide':

     32,114,221,998      cycles
     41,520,220,110      instructions
      9,821,110,002      msr/aperf/
     12,480,003,000      msr/mperf/

       10.002018749 seconds time elapsed

Ce que cela signifie : Le ratio aperf/mperf indique la fréquence réelle par rapport à la nominale. Un ratio plus bas sous certaines charges peut signaler des limites puissance/thermiques ou des offsets liés aux instructions vectorielles.

Décision : Si la fréquence s’effondre uniquement quand un binaire spécifique tourne (crypto, compression, ML), isolez‑le ou planifiez la capacité en supposant l’horloge plus basse.

Tâche 11 : Confirmer les C-states et le comportement d’inactivité (compromis sur la latence)

cr0x@server:~$ sudo cpupower idle-info | head -n 12
CPUidle driver: intel_idle
CPUidle governor: menu
analyzing CPU 0:
  Number of idle states: 4
  C1: type:C1 latency:2 us
  C3: type:C3 latency:80 us
  C6: type:C6 latency:104 us
  C7: type:C7 latency:109 us

Ce que cela signifie : Les états d’inactivité profonds économisent de l’énergie mais peuvent ajouter de la latence de réveil. Cela interagit avec le turbo car le CPU peut accélérer rapidement après le réveil, mais votre requête a déjà attendu.

Décision : Pour les systèmes ultra‑faible latence, envisagez de limiter les C‑states profonds — mais seulement après mesure. Vous échangez puissance/thermique contre latence tail.

Tâche 12 : Vérifier le driver de mise à l’échelle de fréquence au niveau OS

cr0x@server:~$ cpupower frequency-info | egrep 'driver|policy|current CPU frequency'
driver: intel_pstate
current policy: frequency should be within 800 MHz and 3900 MHz.
current CPU frequency: 2.30 GHz (asserted by call to hardware)

Ce que cela signifie : Le driver de scaling affecte la façon dont l’OS demande des changements de fréquence et comment il interprète les états matériels.

Décision : Si vous cherchez la prévisibilité, standardisez les combinaisons driver/gouverneur sur la flotte et documentez la raison.

Tâche 13 : Repérer le masquage par la virtualisation (voyez‑vous vraiment les horloges ?)

cr0x@server:~$ systemd-detect-virt
kvm

Ce que cela signifie : Dans une VM, la télémétrie de fréquence peut être synthétique ou dépendante de l’hôte. Les décisions de turbo se prennent sur l’hôte, pas dans votre invité.

Décision : Pour le débogage de performance, reproduisez sur du bare metal ou assurez‑vous que l’hyperviseur expose des compteurs précis et ne sur‑committe pas les hôtes en throttling permanent.

Tâche 14 : Valider l’exposition du throttling CPU via /proc (compteurs rapides)

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu*/thermal_throttle/* 2>/dev/null | head
/sys/devices/system/cpu/cpu0/thermal_throttle/core_throttle_count:0
/sys/devices/system/cpu/cpu0/thermal_throttle/package_throttle_count:12

Ce que cela signifie : Des compteurs de throttle non nuls indiquent des événements réels, pas des impressions.

Décision : Si les compteurs augmentent pendant des incidents, corrélez‑les avec la température et la télémétrie ventilateur ; traitez‑le comme un problème SRE, pas un problème développeur.

Méthode de diagnostic rapide

Quand la performance est « mystérieusement » mauvaise, vous n’avez pas le temps de devenir historien du micro‑architecture. Vous avez besoin d’une séquence qui converge.

Première étape : décidez si vous êtes limité en puissance, en thermique, ou ni l’un ni l’autre

1. Vérifiez les compteurs/logs de throttling (dmesg, compteurs thermal_throttle). S’ils sont présents, vous êtes probablement thermal‑limited.
2. Vérifiez la température du package et le comportement des ventilateurs (sensors, télémétrie BMC). Si la température est élevée, arrêtez‑vous ici et réparez le refroidissement/flux d’air.
3. Vérifiez la puissance du package par rapport aux limites (turbostat PkgWatt et limites RAPL). Si la puissance atteint un plafond dur et que la fréquence est basse, vous êtes limité en puissance.

Deuxième étape : vérifiez quelle fréquence vous obtenez réellement sous la charge réelle

1. Exécutez turbostat --Summary pendant une charge stable et capturez Bzy_MHz et PkgTmp.
2. Comparez avec les nombres attendus soutenus all‑core pour ce SKU (depuis vos propres tests en labo, pas la page marketing).
3. Si vous êtes dans une VM, confirmez si l’hôte est sur‑engorgé ou plafonné en puissance ; les compteurs invités peuvent mentir par omission.

Troisième étape : vérifiez le mix d’instructions et la contention

1. Corrélez les baisses de fréquence avec des jobs ou binaires spécifiques (crypto, compression, ML, média). Si oui, suspectez des offsets AVX ou des pics de puissance.
2. Vérifiez la file d’exécution et le CPU steal (sur VM) pour séparer « CPU lent » de « CPU qui n’est pas à vous ».
3. Confirmez la pression mémoire et le comportement de cache‑miss si la fréquence est normale mais le débit bas (l’effondrement d’IPC est une autre affaire).

Blague #2 : Si votre serveur « supporte le turbo », cela ne signifie pas qu’il « aime le turbo » dans un rack à 35°C.

Erreurs courantes : symptômes → cause racine → correctif

1) « Nous avons acheté des CPUs 3,5 GHz, pourquoi voyons‑nous 2,2 GHz sous charge ? »

Symptômes : Débit inférieur aux attentes ; p95/p99 augmente sous charge soutenue ; horloges chutent après un sursaut initial.

Cause racine : Confusion base/turbo ; PL1 bas ; la charge active des offsets AVX ; la fenêtre de puissance soutenue est expirée.

Correctif : Mesurez Bzy_MHz soutenu sous charge réelle ; ajustez la politique power du BIOS si possible ; planifiez la capacité sur l’état stable, pas sur la première minute.

2) Pics de latence toutes les quelques minutes comme une horloge

Symptômes : Pics p99 périodiques ; graphiques de température du CPU en dents de scie ; ventilateurs qui montent/descendent ; pas de pattern GC évident.

Cause racine : Oscillation de throttling thermique due à un refroidissement limite ou des réglages turbo/puissance trop agressifs.

Correctif : Améliorez le flux d’air/refroidissement ; nettoyez les filtres ; vérifiez le montage des dissipateurs ; réduisez légèrement les limites de puissance soutenue pour éviter l’oscillation ; re‑vérifiez après stabilisation.

3) « Nous avons forcé le gouverneur performance et c’était pire »

Symptômes : Meilleure latence médiane, pire latence tail ; températures d’entrée/CPU plus élevées ; compteurs de throttling en hausse.

Cause racine : Fréquence constamment élevée réduit la marge thermique ; déclenche le throttling ; augmente parfois l’interaction négative avec les charges voisines.

Correctif : Annulez les changements globaux ; appliquez un tuning par service ; envisagez de plafonner la fréquence ou la puissance pour rester sous le seuil thermique critique ; surveillez les compteurs de throttle.

4) Les benchmarks montrent de gros gains, la production rien

Symptômes : Les tests synthétiques s’améliorent ; le trafic réel reste inchangé ; la fréquence n’est haute que brièvement.

Cause racine : La durée du benchmark tient dans la fenêtre turbo ; la production est soutenue. Ou le benchmark utilise moins de cœurs que la production.

Correctif : Prolongez les benchmarks au‑delà de la fenêtre de puissance ; testez à la concurrence de production ; incluez caches chauds et mix d’instructions réel.

5) « Le CPU va bien » parce que l’utilisation est basse

Symptômes : Faible CPU% mais latence élevée ; temps de requête dominé par le « traitement » et non l’E/S ; fréquence basse lors des transitions idle→busy.

Cause racine : C‑states profonds et scaling conservateur provoquent des délais de réveil et de montée en fréquence ; les moyennes d’utilisation cachent les rafales.

Correctif : Mesurez l’impact de la latence de réveil ; pour des SLOs stricts, limitez les C‑states profonds et assurez‑vous que la politique du gouverneur correspond à la charge. Validez les thermiques après modification.

6) Performance VM très variable entre instances identiques

Symptômes : Même code, même nombre de « vCPU », débit différent ; suspicion de voisin bruyant ; horloges qui semblent « bloquées ».

Cause racine : Plafonds de puissance au niveau hôte, sur‑engagement ou scaling de fréquence ; le guest ne peut pas contrôler le turbo ; steal time et contention d’ordonnanceur.

Correctif : Mesurez le CPU steal ; épinglez les charges critiques sur des hôtes/instances dédiés si nécessaire ; traitez « vCPU » comme une unité d’ordonnancement, pas comme une promesse en GHz.

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

Checklist A : Établir une baseline réaliste de « turbo soutenu » pour un SKU CPU

1. Choisissez une charge représentative (ou une relecture) qui correspond au mix d’instructions et à la concurrence en production.
2. Exécutez‑la suffisamment longtemps pour dépasser les fenêtres turbo (pensez 20–60 minutes, pas 60 secondes).
3. Collectez : résumé turbostat, températures, puissance, compteurs de throttle et débit/latence.
4. Enregistrez le Bzy_MHz soutenu à l’état stable et les watts/temps associés.
5. Stockez les résultats comme baseline interne pour la planification de capacité et les comparaisons d’achat.

Checklist B : Prêt pour la production des services sensibles au turbo

1. Décidez ce que vous optimisez : débit, latence médiane ou latence tail. Choisissez un objectif SLO principal.
2. Standardisez la politique de puissance BIOS sur la flotte (ou par cluster) et documentez‑la.
3. Standardisez les réglages gouverneur/driver et validez après les montées de noyau.
4. Ajoutez des tableaux de bord : fréquence (proxy Bzy_MHz), température package, watts package, compteurs de throttle et latence des requêtes.
5. Alertez sur « compteurs de throttle en hausse + latence en hausse », pas uniquement sur la température.

Checklist C : Quand désactiver le turbo (oui, parfois)

1. Si vous exécutez des charges strictement déterministes où la variance nuit plus que la vitesse (certains systèmes de trading, certaines boucles de contrôle).
2. Si le refroidissement est limite et que vous ne pouvez pas le réparer rapidement, désactiver le turbo peut réduire l’oscillation et stabiliser le p99.
3. Si vous êtes plafonné en puissance au niveau du rack et que le turbo cause des pointes synchronisées qui déclenchent les politiques.

Mais ne le faites pas rituellement. Mesurez avant et après. Vous payez peut‑être pour de la performance puis vous la jetez pour le confort d’une courbe plate.

FAQ

1) Turbo Boost, c’est juste de l’overclocking ?

C’est de l’overclocking contrôlé et supporté par le fournisseur dans des limites définies. Le CPU augmente la fréquence lorsque les conditions puissance/thermiques/courant le permettent, et réduit quand elles ne le permettent plus.

2) Pourquoi mon CPU n’atteint jamais la fréquence turbo maximale annoncée ?

Parce que ce maximum est généralement un pic en meilleur cas sur un petit nombre de cœurs, dans des conditions spécifiques. Une charge all‑core, un travail lourd en AVX, des plafonds de puissance et la température vont la réduire.

3) Quelle est la différence entre fréquence de base et fréquence turbo pour la planification de capacité ?

La base est plus proche d’une garantie durable sous l’enveloppe de puissance prévue. Le turbo est variable. Pour planifier, mesurez le comportement soutenu de votre charge et traitez le turbo comme une marge opportuniste.

4) Une mise à jour BIOS peut‑elle changer le comportement du turbo ?

Oui. Le firmware peut changer les limites de puissance par défaut, les fenêtres temporelles et les profils de performance. Traitez les mises à jour BIOS comme des changements de performance : testez les horloges soutenues et le throttling après chaque mise à jour.

5) Pourquoi le chiffrement/la compression rend le CPU « plus lent » ?

Ces charges peuvent utiliser des instructions vectorielles et augmenter la densité de puissance. Le CPU peut réduire la fréquence pour rester dans les contraintes puissance/thermiques. Le travail par cycle peut s’améliorer, mais le nombre de cycles par seconde peut diminuer.

6) Dois‑je exécuter le gouverneur Linux en mode performance sur les serveurs ?

Parfois. Cela peut réduire la latence de montée en fréquence et améliorer la latence tail — jusqu’à ce que cela vous pousse dans le throttling thermique. Si vous ne pouvez pas prouver la marge thermique sous le pic de trafic, n’activez pas cela globalement.

7) Dans une VM, puis‑je contrôler le turbo ?

Pas directement. Le turbo se décide sur l’hôte. Les invités peuvent demander du comportement via des interfaces virtualisées, mais la politique d’alimentation/thermique de l’hôte l’emporte. Pour des performances prévisibles, il faut des garanties au niveau hôte.

8) Sur quels métriques devrais‑je alerter pour les incidents liés au turbo ?

Compteurs de throttle en hausse, température package proche des limites, puissance package bloquée à un plafond, et chute de la fréquence effective busy corrélée à une régression de latence/débit.

9) Désactiver le turbo améliore‑t‑il la fiabilité ou la durée de vie du matériel ?

Cela peut réduire la chaleur et les pics de puissance, ce qui rend généralement les systèmes plus sages. Mais la fiabilité concerne surtout le respect des limites de conception. Si vous refroidissez déjà correctement et n’avez pas de pics de puissance, le turbo n’est pas en soi imprudent.

10) Pourquoi des serveurs « identiques » montrent‑ils des comportements turbo différents ?

Différences dans les defaults firmware, le refroidissement (courbes de ventilateur, poussière, flux d’air), le comportement des VRM, la température ambiante et même de petites variations de silicium peuvent déplacer les horloges soutenues. Mesurez, ne présumez pas.

Prochaines étapes concrètes

1. Cessez d’utiliser « max turbo » dans les slides de capacité. Remplacez‑le par une fréquence soutenue mesurée sous votre charge et votre concurrence.
2. Ajoutez de la télémétrie aware‑turbo. Mettez la température package, les compteurs de throttling et le MHz effectif busy à côté de vos graphiques de latence. La corrélation vaut mieux que la superstition.
3. Choisissez une politique plateforme en connaissance de cause. Décidez si vous optimisez pour le débit ou la latence tail, puis alignez limites BIOS, gouverneurs et refroidissement sur cette décision.
4. Caractérisez le nouveau matériel comme s’il pouvait vous trahir. Parce qu’il peut — poliment, dans le respect des specs, et au pire moment.

Si vous ne faites qu’une seule chose : lancez un test soutenu qui dure plus longtemps que la fenêtre turbo, et traitez ce chiffre d’état stable comme la réalité. Le turbo peut être un cadeau. Ce n’est juste pas un contrat.