PL1, PL2 y Tau explicados: Los tres números que lo deciden todo

El modelo mental: potencia, tiempo y “¿por qué se ralentizó?”

Una CPU es básicamente un convertidor de potencia a trabajo envuelto en un problema térmico. La frecuencia y el voltaje determinan cuánto trabajo puede hacer por segundo.
Pero la frecuencia y el voltaje también determinan cuánta potencia consume, y la potencia se convierte en calor. El calor debe salir del encapsulado, entrar en el disipador
y luego escapar al aire ambiente. Esa cadena tiene límites.

PL1, PL2 y Tau son la forma en que la CPU juega limpio con la física mientras el marketing sigue mostrando números bonitos de boost.
Definen un presupuesto: cuánto puede gastar la CPU de forma continua (PL1), cuánto puede sobrepasar brevemente (PL2),
y durante cuánto se tolera ese sobreconsumo (Tau). Si no recuerdas nada más, recuerda esto:
PL2 es tu “explosión”, PL1 es tu “estado estacionario” y Tau es el temporizador de paciencia.

En sistemas de producción, estos números aparecen como:

• Las solicitudes arrancan rápido y luego la latencia de la cola sube tras unos segundos de carga sostenida.
• Los trabajos por lotes muestran una curva de rendimiento en “dientes de sierra”: boost, límite, recuperación, repetir.
• Dos máquinas “idénticas” rinden distinto porque un fabricante de placas decidió interpretar “por defecto” de forma creativa.
• Mejoras en la refrigeración no ayudan tanto como se esperaba porque el sistema está limitado por potencia, no por temperatura.

Chiste #1: Una CPU sin límites de potencia sensatos es como un buffet sin platos: todos están entusiasmados hasta que el suelo se cubre de pasta.

Los mejores operadores tratan los límites de potencia como cualquier otro control de producción:
definir un objetivo, aplicarlo de forma consistente y alertar por desviaciones. “Valores por defecto” no son una estrategia.

PL1, PL2, Tau: definiciones útiles para una sala de crisis

PL1: límite de potencia a largo plazo (estado estacionario)

PL1 es la potencia promedio a largo plazo que se permite consumir a la CPU. En muchos entornos se corresponde de forma laxa con el TDP,
pero “de forma laxa” es una gran advertencia aquí. Si tu carga es sostenida—codificación, compactación, analítica, escaneo AV, consolidación de VMs—PL1 es
el número que determina el techo de rendimiento a largo plazo.

Cuando la CPU alcanza PL1, reduce la frecuencia (y a veces el voltaje) para mantener la potencia promedio del paquete en o por debajo de ese límite.
Esto puede ocurrir aunque las temperaturas parezcan bien. Ese es un punto clave: la limitación por potencia no siempre es limitación térmica.

PL2: límite de potencia a corto plazo (ráfaga)

PL2 es un límite de potencia mayor que la CPU puede usar por un breve intervalo. Esto es lo que hace que tu sistema se sienta ágil:
ráfagas en la interfaz, fases cortas de compilación, consultas inmediatas, picos de solicitudes de corta duración. PL2 es donde vive el “turbo”.

Si PL2 está configurado de forma agresiva y la refrigeración es mediocre, la CPU acelerará mucho, se calentará rápido y luego golpeará otro limitador:
o bien agota Tau y cae a PL1, o bien alcanza límites térmicos (TJmax, PROCHOT) y cae aún más.

Tau: la ventana temporal (cuánto tiempo se permite PL2)

Tau es la constante de tiempo / ventana que controla cuánto tiempo la CPU puede exceder PL1 hasta PL2 antes de tener que frenarse.
En la práctica, muchas plataformas lo implementan con un promedio móvil de la potencia del paquete sobre una ventana temporal.
Si la potencia promedio en ese intervalo excede PL1, la CPU reduce la frecuencia para bajar la media.

El síntoma clásico de Tau es: “Todo va rápido durante 10–60 segundos, luego el rendimiento baja y se mantiene más bajo.”
Eso no es misterioso. Eso es Tau haciendo exactamente lo que se le indicó.

Una definición más que verás: “ilimitado”

Algunas BIOS y herramientas de fabricantes ofrecen PL2 “ilimitado” o Tau muy alto. Esto suele significar “hasta que otra cosa entre en pánico”,
no “para siempre”. Lo que suele entrar en pánico es típicamente la temperatura, límites de corriente del VRM, límites de temperatura de la carcasa o presupuestos de potencia de la plataforma.
“Ilimitado” es genial para benchmarks y terrible para sistemas predecibles.

Cómo las CPU aplican los límites (y por qué se siente personal)

Las CPU modernas tienen múltiples capas de gobernadores y límites duros. Los límites de potencia se aplican mediante lógica en el propio chip usando telemetría:
estimación de potencia del paquete, corriente consumida, sensores de temperatura y a veces señales externas de la plataforma desde el controlador de la placa.
Cuando se excede un límite, la CPU no negocia. Ajusta la frecuencia, el voltaje y puede restringir los bins de turbo.

La jerarquía de aplicación varía según la generación y el fabricante, pero típicamente verás:

• Limitación por potencia: la potencia del paquete excede PL1/PL2 (a menudo reportado como “PL1/PL2” o “Power Limit”).
• Limitación térmica: la temperatura se acerca a TJmax; la CPU reduce frecuencia para mantenerse bajo el techo térmico.
• PROCHOT: señal de “processor hot”—puede ser activada por la CPU o por la plataforma; limita de forma agresiva.
• Límites de corriente/VRM: la VRM de la placa no puede suministrar de forma segura la corriente solicitada; la entrega de potencia se convierte en el techo.
• Límites de plataforma: el EC del portátil impone presupuestos de batería/adaptador; los servidores aplican límites de potencia por rack.

Punto operativo importante: el limitador que ves no siempre es la causa raíz. Un límite de potencia puede causar menor frecuencia, lo que reduce calor,
ocultando un problema térmico. O un problema térmico puede forzar la caída de frecuencia, lo que reduce potencia y hace parecer que estás “dentro de PL1.”
Diagnosticas correlacionando: frecuencia, temperatura, potencia del paquete y banderas de throttling—a lo largo del tiempo.

Una cita, porque sigue siendo el mejor consejo en operaciones. Gene Kranz, director de vuelo de la NASA, dijo:
“Tough and competent.”
En el mundo de los límites de potencia, “tough” significa no tocar los ajustes por pánico; “competent” significa medir antes de mover perillas.

Qué cambia cuando ajustas cada número

Aumentar PL1: mejor rendimiento sostenido, más calor constante, mayor factura eléctrica

Subir PL1 aumenta el rendimiento sostenido si (y solo si) la CPU estaba previamente limitada por potencia bajo tu carga en estado estable.
También incrementa la carga térmica constante. Si tu disipador y el flujo de aire del chasis no pueden evacuar ese calor, solo cambiarás
la limitación por potencia por limitación térmica. Eso no es una mejora; es otro tipo de miseria.

Aumentar PL2: ráfagas más ágiles, potencialmente peor estabilidad con cargas explosivas

PL2 afecta la capacidad de respuesta y los benchmarks cortos. En servidores, afecta el comportamiento de cola durante picos breves de carga.
Puedes obtener ganancias reales para servicios con ráfagas (frontends de API, caches que se calientan, pasos cortos de compilación).
Pero si PL2 es demasiado alto, puedes activar límites de corriente del VRM, límites del adaptador (portátiles) o transitorios térmicos que
hacen oscilar el sistema. La oscilación es lo que tus gráficos SLO llaman “interesante”.

Cambiar Tau: controla el momento del “precipicio”

Tau determina cuánto tiempo la CPU puede comportarse como un velocista antes de verse forzada a ritmo de maratón.
Aumentar Tau suele mejorar los resultados de benchmarks y puede ayudar en cargas que terminan rápido.
También puede empeorar cargas sostenidas si hace que el sistema se caliente antes, saturando los ventiladores
y provocando más throttling térmico posteriormente. Por eso “solo aumenta Tau” es un meme, no un plan.

Reducir límites: la medida infravalorada

En producción, bajar PL2 y/o PL1 puede incrementar la previsibilidad, reducir el ruido de los ventiladores (sí, importa en oficinas y laboratorios),
y mantener los sistemas dentro de los presupuestos de energía del rack. Esto es especialmente útil en despliegues densos donde un nodo a todo turbo
puede acercar peligrosamente una rama del PDU a sus límites.

Chiste #2: Configurar PL2 a tope porque “pagamos por turbo” es como quitar el limitador de velocidad de una furgoneta de reparto—genial hasta que las ruedas presentan una queja.

Dónde los configures importa: BIOS vs OS vs herramientas del fabricante

Puedes ajustar límites de potencia en la BIOS/UEFI, a través de interfaces a nivel de SO (RAPL en Intel, perfiles de plataforma, powercap), o mediante daemons del fabricante.
La BIOS suele ser la opción más estable y menos sorprendente. El control desde el SO es potente pero más propenso a desviaciones por actualizaciones o mala configuración.
Las herramientas del fabricante suelen ser opacas y, en ocasiones, “útiles” en el mismo sentido en que un niño pequeño ayuda a cocinar.

Datos interesantes y breve historia

• Los límites de potencia se hicieron comunes cuando el turbo se popularizó. Turbo boost creó la necesidad de presupuestos explícitos y aplicables más allá del “TDP”.
• RAPL existe porque no puedes gestionar lo que no puedes medir. Las interfaces Running Average Power Limit de Intel trajeron la potencia al control por software.
• Los valores de Tau a menudo coinciden con ventanas de benchmarks “bonitas”. Muchos Tau por defecto caen en rangos de decenas de segundos, lo cual es… conveniente.
• Los fabricantes de placas tratan los “valores por defecto de Intel” como una sugerencia. Algunas placas salen con PL2/Tau elevados para ganar reseñas, y luego tu datacenter paga la factura.
• PL1 no siempre es igual a TDP. Los OEM pueden fijar PL1 por encima o por debajo del TDP nominal según la refrigeración y los objetivos del producto.
• La gestión de potencia es un problema de plataforma, no solo de CPU. El diseño del VRM, límites de la PSU, flujo de aire del chasis y controladores embebidos pueden anular tus ajustes.
• La telemetría es imperfecta. La potencia del paquete suele estimarse, no medirse directamente, y la precisión varía con la plataforma y la calibración.
• El “diseño térmico” incluye tiempo. La capacitancia térmica significa que un sistema puede absorber calor temporalmente—exactamente lo que explota Tau.
• Los centros de datos ya limitan la potencia—a nivel de rack—las CPU solo lo internalizaron. Los presupuestos de rack y PDU forzaron consumo predecible; los límites a nivel de CPU son la extensión granular.

Guía rápida de diagnóstico

Cuando el rendimiento baja bajo carga, quieres identificar el limitador rápido. No empieces cambiando la BIOS.
Empieza por probar si estás limitado por potencia, por temperatura o por otra cosa (planificador, IO, ancho de banda de memoria).

Primero: confirma el patrón de síntomas

• ¿El rendimiento baja después de una ventana temporal consistente (10–60 segundos)? Piensa en Tau/PL1.
• ¿Cae inmediatamente cuando la temperatura se acerca a TJmax? Piensa en limitación térmica / refrigeración.
• ¿Oscila en ciclos de unos pocos segundos? Piensa en límites VRM/corriente, PL2 agresivo o retardo en el control de los ventiladores.

Segundo: captura potencia + frecuencia + banderas de throttling juntas

• Usa turbostat (Intel) o herramientas del proveedor relevantes para capturar: potencia del paquete, MHz, temperatura y razones de throttling.
• Correlaciona con dmesg para mensajes térmicos/PROCHOT y con journalctl para daemons de plataforma que cambien políticas.

Tercero: verifica qué límites están configurados y quién los estableció

• Lee los valores de powercap RAPL desde sysfs; compáralos con lo esperado por la BIOS.
• Comprueba si un daemon del proveedor o un perfil de energía está reescribiendo límites en tiempo de ejecución.
• En hosts virtualizados, comprueba si políticas del hipervisor limitan la potencia indirectamente (por ejemplo, perfiles de potencia, cgroups, gobernadores cpufreq).

Cuarto: decide la clase de solución

• Si estás limitado por potencia pero las térmicas están bien: aumenta PL1 con moderación, o acepta el límite y planifica capacidad en consecuencia.
• Si estás limitado térmicamente: arregla la refrigeración primero; subir PL1 solo hará que se limite más agresivamente.
• Si estás limitado por corriente/VRM: reduce PL2 o mejora la placa/PSU; no puedes “tunear” una entrega de potencia débil hasta convertirla en fuerte.
• Si no es limitación de CPU: deja de tocar ajustes de PL y busca el cuello de botella real.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son las comprobaciones que realmente hago cuando alguien dice “la CPU se está limitando”.
Las líneas de comando son centradas en Linux porque la producción suele ser Linuxera. Ajusta para tu entorno.

Task 1: Identify CPU model and platform basics

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

Qué significa: Necesitas la SKU exacta porque los valores PL por defecto varían según SKU, OEM y microcódigo.
La línea de MHz actual normalmente no es suficiente para el diagnóstico pero ancla tus expectativas.
Decisión: Registra el modelo de CPU antes de comparar nodos o culpar a “hardware idéntico”.

Task 2: Check current frequency behavior under load

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

Qué significa: Esto crea una carga sostenida controlada. Las métricas te permiten comparar “antes/después” de los cambios.
Decisión: Ejecuta esto junto a turbostat para ver si el rendimiento decae durante la prueba.

Task 3: Capture turbo, power, and throttling flags with 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

Qué significa: Puedes ver literalmente la caída: la potencia del paquete baja y los MHz caen después de unos segundos.
Eso es consistente con Tau expirando y asentándose cerca de PL1.
Decisión: Si PkgTmp está estable por debajo de TJmax pero los MHz bajan con PkgWatt, probablemente estás limitado por potencia (PL1), no térmicamente.

Task 4: Check kernel logs for thermal and PROCHOT events

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)

Qué significa: Esto es evidencia real de throttling térmico. Si ves esto, deja de “tunear PL” y arregla la refrigeración.
Decisión: Trata eventos repetidos como un problema de fiabilidad; el estrés térmico reduce la vida útil y aumenta las tasas de error.

Task 5: Read RAPL power limit values from 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

Qué significa: El límite a largo plazo es 95W (PL1), la ventana de tiempo es 28 segundos (Tau), el límite a corto plazo es 125W (PL2).
Las unidades son microvatios y microsegundos.
Decisión: Si estos valores no coinciden con lo que crees que la BIOS debería establecer, algo (firmware, SO, daemon) los está sobreescribiendo.

Task 6: Observe current package energy and compute average power

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

Qué significa: Este contador incrementa con la energía consumida (microjulios). Muéstralo dos veces con marcas temporales para calcular la potencia promedio.
Decisión: Úsalo cuando no puedas confiar en herramientas de alto nivel, o para verificar turbostat.

Task 7: Check who is managing CPU frequency policy (governor)

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

Qué significa: El governor afecta la selección de frecuencia pero no anula los límites duros de potencia.
Si estás en powersave, podrías estar auto-limitándote antes de que los límites PL importen.
Decisión: Para pruebas de rendimiento coherentes, usa performance. Para política de flota, elige con intención.

Task 8: Detect if intel_pstate is in active mode and what the caps are

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

Qué significa: Estás usando intel_pstate con el máximo de rendimiento permitido.
Si max_perf_pct es bajo, alguien te ha capado y culparás injustamente a PL1.
Decisión: Mantén esto consistente entre nodos antes de comparar rendimiento.

Task 9: Check for runtime power management daemons changing policy

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

Qué significa: Estos servicios pueden influir en perfiles de rendimiento y comportamiento térmico. En portátiles y algunos servidores, también pueden escribir límites de potencia.
Decisión: Para experimentos controlados, para temporalmente (con cuidado) o al menos conoce que existen.

Task 10: Verify if the platform exposes throttle reasons (turbostat flags)

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

Qué significa: Algunas compilaciones de turbostat muestran columnas explícitas de throttling; otras no dependiendo del kernel y el soporte de la CPU.
Incluso sin banderas, la correlación entre MHz y PkgWatt es una pista fuerte.
Decisión: Si no puedes ver banderas, compensa con los límites RAPL en sysfs y los logs del kernel.

Task 11: Change PL1/PL2/Tau (carefully) 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

Qué significa: Subiste PL1 a 105W, PL2 a 140W, Tau a 35s. Esto puede o no persistir tras reiniciar.
Decisión: Haz esto solo en un nodo de prueba primero. Luego vuelve a ejecutar la carga + captura con turbostat y compara.

Task 12: Validate the change’s real effect using a repeatable benchmark

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

Qué significa: Si bogo ops/s mejora y se mantiene estable durante la prueba, tu nuevo estado estacionario es mejor.
Si mejora al principio pero luego retrocede, probablemente empujaste al sistema a límites térmicos/transitorios de corriente.
Decisión: Mantén el cambio solo si mejora el rendimiento sostenido sin aumentar eventos de throttling o logs de errores.

Task 13: Check actual temperature sensors and fan behavior

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)

Qué significa: Estás cerca de los límites alto/crítico. Incluso si ahora estás “solo” limitado por potencia, no tienes margen térmico.
Decisión: No subas los límites PL en una máquina que vive a 92°C bajo carga rutinaria. Arregla flujo de aire, curvas de ventilador, polvo o montaje del disipador primero.

Task 14: Check if cgroups are capping CPU (common in containers)

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

Qué significa: Esto indica que el cgroup puede usar 80% de una CPU por periodo de 100ms (cgroup v2). Es un tope artificial.
Decisión: Si lo ves, tu “throttling” puede ser el scheduler del cgroup, no PL1/PL2. Arregla límites de orquestación antes de afinar potencia.

Task 15: Spot a BIOS/firmware mismatch across nodes

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

Qué significa: Las diferencias de versión de BIOS suelen implicar comportamientos por defecto distintos en PL/Tau.
Decisión: En flotas, estandariza versiones de BIOS (y ajustes) antes de intentar forense de rendimiento.

Tres microhistorias corporativas del campo

1) El incidente causado por una suposición equivocada: “TDP equivale a rendimiento”

Una compañía SaaS de tamaño medio desplegó una tanda de servidores “mismo CPU, misma RAM” para un servicio sensible a la latencia.
Reemplazaban hosts antiguos que ya estaban al límite de capacidad, así que las expectativas eran simples: misma SKU, máquinas más nuevas, deberían ser iguales o mejores.

La primera semana en staging parecía bien. Luego en producción vieron un patrón raro: las mañanas eran estupendas, las tardes eran horribles.
La latencia p95 derivó al alza durante la meseta diaria de tráfico, pero la utilización de CPU parecía normal.
La primera reacción fue clásica: “debe ser el garbage collection” (no lo era), luego “debe ser la red” (tampoco).

Un SRE finalmente graficó el throughput por host con una carga sintética y notó una caída consistente tras ~30 segundos.
Ese fue el indicio. Los servidores viejos tenían una configuración turbo conservadora: PL2 moderado, Tau sensato, estado estacionario estable.
Los nuevos venían con un perfil OEM de “rendimiento”: PL2 más alto y un Tau lo bastante largo como para empapar térmicamente el chasis,
y un PL1 que resultó ser más bajo de lo esperado cuando el controlador embebido empezó a proteger las térmicas de la plataforma.

La suposición equivocada no fue “el turbo es malo.” La suposición equivocada fue “TDP es una propiedad de la CPU, así que el comportamiento debe coincidir.”
En la práctica, el firmware de la plataforma, el VRM y la refrigeración definen el estado estacionario real. La misma CPU en dos chasis no es el mismo producto.

Lo arreglaron estandarizando ajustes de BIOS entre proveedores: valores explícitos de PL1/PL2/Tau probados contra su carga real.
La latencia se estabilizó. El consumo se volvió predecible. Compras aprendió una nueva regla: “Misma SKU” no es una prueba de aceptación.

2) La optimización que salió mal: “Subir PL2 para despliegues más rápidos”

Una gran empresa tenía una flota de CI donde los tiempos de compilación y pruebas iban en aumento. Alguien propuso una solución clara:
“Estas CPUs soportan más potencia de turbo. Vamos a subir PL2 y Tau para que las builds terminen más rápido.”
Funcionó en un sentido limitado. El tiempo medio de compilación mejoró. Los gráficos en la reunión quedaron bonitos.

Dos semanas después la flota empezó a sufrir fallos intermitentes: reinicios aleatorios de workers, comprobaciones de máquina del kernel ocasionales,
y ese tipo de comportamiento inestable que hace que los equipos culpen a “rayos cósmicos” y luego cambien de tema en voz baja.
El diagnóstico de hardware no encontró nada obvio. Las temperaturas ni siquiera eran alarmantes—solo espigas.

El problema real eran los transitorios. Subir PL2 y Tau provocó picos repetidos de corriente durante compilaciones paralelas.
La combinación VRM/PSU en ese chasis en particular aguantaba la carga media pero detestaba ráfagas repetidas a potencia elevada.
El sistema se mantenía “dentro de límites térmicos” mientras estresaba componentes de entrega de potencia.
Los fallos se agruparon en periodos de alta concurrencia de builds donde los patrones de ráfagas coincidían.

Revertir el cambio eliminó los reinicios. Luego reintrodujeron una versión más segura: aumento moderado de PL2 con Tau más corto,
además de un tope de concurrencia por host para suavizar los patrones de carga. El tiempo medio de compilación quedó algo peor que el pico imprudente,
pero la tasa de fallos volvió a la normalidad, que es el KPI que importa cuando suena el pager.

La moraleja: aumentar PL2 no es gratis. Cambia el estrés de “calor con el tiempo” a “corriente ahora”. La corriente inmediata es cómo descubres eslabones débiles.

3) La práctica aburrida pero correcta que salvó el día: “Límites explícitos y detección de desviaciones”

Una fintech gestionaba una flota mixta: algunos nodos nuevos, otros viejos, algunos en un centro de datos y otros en otro.
Tenían requisitos de rendimiento estrictos durante horas de mercado y presupuestos de potencia estrictos en una instalación que ya rozaba los límites de PDU.
Todos querían “máximo rendimiento”, pero nadie quería un incidente de potencia durante el trading.

Hicieron lo aburrido. Crearon un documento de perfil de hardware por plataforma que listaba explícitamente PL1/PL2/Tau,
ajustes de BIOS, perfiles de ventiladores y ajustes del governor del SO. Lo aplicaron con gestión de configuración que validaba los valores RAPL al arrancar,
y alertaban por desviaciones si un nodo reportaba restricciones distintas a las esperadas.

Meses después, una actualización urgente de microcódigo/BIOS se desplegó por seguridad. Tras la actualización, un subconjunto de nodos cambió
silenciosamente su comportamiento por defecto de Tau y PL2. Sin detección de desviaciones, el equipo lo habría notado solo cuando la latencia de cola empezara a ampliarse.
En cambio, las alertas saltaron en la primera hora tras el reinicio canario.

Reaplicaron el perfil explícito y siguieron adelante. Sin incidente. Sin gráfica misteriosa.
Solo la competencia poco glamurosa que te mantiene empleado.

Errores comunes (síntomas → causa raíz → solución)

1) “Hace boost a 5 GHz y luego cae a 3.8 GHz”

Síntomas: Caída repetible después de una ventana temporal fija; temperaturas no en TJmax.

Causa raíz: Tau expira y la CPU se asienta en el estado estacionario PL1.

Solución: Decide si necesitas rendimiento sostenido (sube PL1 si la refrigeración lo permite) o acepta PL1 y planifica capacidad. Evita “solo sube Tau” a menos que la carga realmente termine dentro de esa ventana ampliada.

2) “Las temperaturas están bien pero el rendimiento es bajo”

Síntomas: MHz bajos bajo carga, potencia del paquete baja, sin logs térmicos.

Causa raíz: Política del SO (intel_pstate max_perf_pct, governor cpufreq), límites de cgroup, o perfil de potencia del hipervisor.

Solución: Verifica el governor, las caps de intel_pstate y las cuotas de CPU de cgroup antes de tocar los límites PL.

3) “Subimos PL1 y empeoró el rendimiento”

Síntomas: Mayor potencia inicial, luego throttling más agudo; más eventos térmicos; ventiladores al máximo.

Causa raíz: Pasaste de un estado limitado por potencia a uno limitado térmicamente (TJmax/PROCHOT).

Solución: Mejora la refrigeración (colocación del disipador, flujo de aire, curva de ventiladores, ambiente). Luego reevalúa PL1. Si no puedes refrigerar, no le des más potencia.

4) “Reinicios aleatorios tras ajustar el turbo”

Síntomas: Inestabilidad con cargas paralelas explosivas; sin apagado térmico claro; errores de hardware esporádicos.

Causa raíz: Estrés transitorio en VRM/PSU por PL2/Tau agresivos; límites de entrega de potencia de la plataforma.

Solución: Reduce PL2 y/o Tau; suaviza la concurrencia de la carga; asegúrate de que PSU/VRM y BIOS estén validados para ese perfil de potencia.

5) “Dos servidores idénticos rinden distinto”

Síntomas: Misma SKU de CPU, distintos MHz sostenidos y potencia; resultados de benchmark inconsistentes.

Causa raíz: Versiones de BIOS diferentes, perfiles por defecto del proveedor, o distinta refrigeración/VRM del chasis.

Solución: Estandariza la configuración de BIOS; lee las restricciones RAPL; trata “misma SKU” como insuficiente.

6) “Pusimos límites en el SO pero se revierten”

Síntomas: Valores en sysfs cambian tras reiniciar o cuando arranca un daemon.

Causa raíz: La BIOS reestablece límites al arrancar, o un daemon de gestión de energía los reescribe en tiempo de ejecución.

Solución: Prefiere BIOS para valores por defecto estables en la flota; si usas control desde el SO, aplícalo en el arranque vía unit de systemd y deshabilita servicios conflictivos.

7) “El portátil pierde rendimiento con batería”

Síntomas: PL1/PL2 dramáticamente más bajos en batería; throttling agudo bajo carga sostenida.

Causa raíz: El controlador embebido impone presupuestos de batería/adaptador y restricciones de temperatura de la carcasa.

Solución: Usa el perfil de energía apropiado; no hagas benchmarks con batería; acepta que la plataforma, no la CPU, manda.

Listas de comprobación / plan paso a paso

Paso a paso: establece una línea base confiable

1. Registra la identidad de la plataforma: modelo de CPU (lscpu), versión de BIOS (dmidecode), versión del kernel, versión de microcódigo.
2. Registra la política: governor (scaling_governor), estado de intel_pstate, daemons de potencia en ejecución.
3. Registra límites configurados: lee las restricciones RAPL (PL1/PL2/Tau) desde sysfs.
4. Ejecuta una carga controlada: por ejemplo, stress-ng durante 60s.
5. Captura telemetría: turbostat a intervalos de 1s, más la salida de sensors cerca del estado estable.
6. Anota el tiempo hasta el precipicio: cuándo ocurre la caída de frecuencia/potencia; compáralo con Tau.

Paso a paso: decide si cambiar límites

1. Si la temperatura está cerca de TJmax: no subas PL1/PL2. Arregla la refrigeración primero.
2. Si PkgWatt se queda en PL1 y la temperatura es segura: considera aumentar PL1 en pequeños incrementos (5–10W) y vuelve a testear.
3. Si solo necesitas ráfagas cortas: ajusta PL2 y Tau para que coincidan con la duración de las ráfagas, no para ganar gráficos sintéticos.
4. Si la estabilidad importa más que el pico: reduce PL2 y/o Tau para disminuir oscilaciones y picos de corriente.
5. Valida con carga similar a producción: no solo CPU sintética; incluye patrones de memoria e IO.

Checklist de flota: evita que esto vuelva a ser un misterio

• Establece PL1/PL2/Tau explícitos en BIOS para cada clase de hardware.
• Almacena “restricciones RAPL esperadas” y verifícalas al arrancar.
• Alerta por desviaciones: si las restricciones cambian, trátalo como drift de configuración.
• Mantén versiones de BIOS consistentes, especialmente tras actualizaciones por seguridad.
• Planifica capacidad usando rendimiento en estado estable (PL1), no ráfagas (PL2).
• Documenta la regla de negocio: ¿optimizas para latencia de ráfagas o para rendimiento sostenido?

Preguntas frecuentes

1) ¿PL1 y TDP son lo mismo?

No de forma fiable. Muchas plataformas fijan PL1 cerca del TDP, pero los OEM pueden ponerlo por encima o por debajo según refrigeración y objetivos de producto.
Trata el TDP como un objetivo térmico vinculado al marketing, no como una garantía de comportamiento sostenido.

2) ¿Por qué veo buenos números en benchmarks pero rendimiento sostenido terrible?

Porque los benchmarks suelen vivir dentro de la ventana PL2/Tau. Miden la carrera corta. Tu carga es un maratón.
Mide en estado estable y observa el comportamiento tiempo-hasta-clamp.

3) Si las temperaturas son bajas, ¿puedo subir PL1 con seguridad?

“Con seguridad” depende del VRM, la PSU y el flujo de aire del chasis, no solo de la temperatura del CPU.
Una temperatura baja sugiere margen térmico, pero aún necesitas validar estabilidad y entrega de potencia bajo ráfagas y carga sostenida.

4) ¿Cuál es un Tau razonable?

Lo razonable depende de la carga. Si tu servicio ve ráfagas de pocos segundos, un Tau largo suele añadir calor y riesgo de oscilación.
Si tus tareas terminan en 20–40 segundos, ajustar Tau puede importar. Para trabajos de larga duración, Tau afecta principalmente el primer minuto y luego manda PL1.

5) ¿Por qué a veces subir PL2 reduce el rendimiento?

Porque puede provocar transitorios térmicos o límites de corriente, causando throttling más agresivo después.
Tienes un inicio más caliente y un aterrizaje peor. El rendimiento se vuelve irregular en vez de estable.

6) ¿Puedo ajustar límites PL dentro de una VM o contenedor?

Normalmente no de forma significativa. Los límites PL se aplican al nivel del host CPU/paquete.
En contenedores puedes limitar CPU vía cgroups; en VMs puedes controlar la programación de vCPU, pero normalmente no puedes reescribir las restricciones RAPL del host.

7) ¿Cuál es la diferencia entre throttling por potencia y por temperatura en síntomas?

El throttling por potencia suele mostrar caída de frecuencia mientras la temperatura se mantiene por debajo de TJmax y la potencia del paquete se queda cerca de un límite.
El throttling térmico muestra la temperatura alcanzando un techo y logs o banderas indicando eventos térmicos; la potencia puede caer como consecuencia.

8) ¿Debería siempre poner perfiles de BIOS en “máximo rendimiento”?

No a ciegas. “Máximo rendimiento” a menudo significa PL2 más alto y Tau más largo, lo que puede violar tu presupuesto de potencia por rack y perjudicar la previsibilidad.
Para producción, elige “rendimiento consistente” a menos que tengas una razón medida para perseguir picos.

9) ¿Los sistemas AMD tienen los mismos conceptos PL1/PL2/Tau?

Los nombres difieren, pero la idea—presupuestos de potencia en ventanas temporales—es común en CPUs modernas.
En AMD verás controles distintos (PPT/TDC/EDC y comportamientos de boost), pero diagnosticas igual: correlaciona relojes, potencia, temperatura y banderas de límite.

10) ¿Cuál es la gráfica más útil para esto?

Frecuencia, potencia del paquete y temperatura en la misma línea temporal durante una prueba de carga sostenida, con banderas de throttling si están disponibles.
El “precipicio” se vuelve obvio y puedes emparejarlo con Tau o con techos térmicos.

Siguientes pasos que puedes hacer ahora

PL1, PL2 y Tau no son trivia. Son política. La política controla rendimiento, térmicas, estabilidad y presupuestos de potencia.
Si los tratas como números mágicos, tendrás problemas mágicos: rendimiento inconsistente, precipicios misteriosos y servidores “idénticos” que no lo son.

Haz esto a continuación:

1. Elige un nodo representativo y captura una prueba de carga de 60 segundos con turbostat + sensors.
2. Lee los PL1/PL2/Tau configurados desde RAPL sysfs y compáralos con el comportamiento observado.
3. Decide qué estás optimizando: latencia de ráfagas o rendimiento sostenido. Escríbelo.
4. Cambia una variable a la vez (PL1 o PL2 o Tau), en pequeños incrementos, y vuelve a probar con la misma carga.
5. Estandariza ajustes de BIOS en la flota y alerta por desviaciones para no redescubrir esto cada trimestre.

Los sistemas predecibles suelen ser un poco menos excitantes. Ese es el punto.