Compras dos CPUs “idénticas” para dos servidores “idénticos”. Mismo modelo. Mismo BIOS. Misma refrigeración. Una máquina funciona sin problemas bajo carga;
la otra corre más caliente, hace menos boost y empieza a generar errores de machine-check corregidos como si buscara atención.
En producción, eso no es trivia. Es un informe de incidente esperando ocurrir.
La verdad incómoda: gran parte de tu parque de hardware es producto de un proceso de clasificación. Un mismo diseño físico de dado se convierte
en múltiples niveles de precio mediante el binning. No es una conspiración. Es la realidad de la fabricación más incentivos comerciales,
envuelta en suficiente marketing para que parezca destino.
Binning en un párrafo
Binning es la práctica de probar el silicio fabricado (CPU/GPU/SoC/DRAM/NAND) y clasificarlo en categorías
(“bins”) según lo que puede hacer de forma fiable: frecuencia a un voltaje dado, fuga/potencia, comportamiento térmico, funciones habilitadas
y tasas de error. Esos bins se convierten en distintas SKUs y niveles de precio. El mismo diseño de dado puede enviarse como una pieza de primera línea,
una pieza de gama media con relojes más bajos, o una pieza de gama baja con núcleos/unidades de caché deshabilitadas. El objetivo es el rendimiento de fabricación:
vender tanto de la oblea como sea posible sin enviar piezas que fallen, estrangulen o violen los límites de potencia.
Del oblea a cinco niveles: la canalización
El binning comienza mucho antes de que tu hoja de cálculo de aprovisionamiento vea un número de pieza. Empieza en la oblea, con cientos (o miles)
de copias del mismo diseño grabadas en silicio. En un universo perfecto, cada dado se comportaría idénticamente. En el universo en el que
realmente operamos, la variación en la fabricación está garantizada y los defectos son inevitables.
1) Fabricación de la oblea y variación
Un nodo de proceso moderno apila complejidad: transistores diminutos, múltiples capas metálicas, silicio deformado, estructuras finas o nanosheets,
y litografía agresiva. Pequeñas diferencias en el ancho de línea, concentración de dopantes y espesor de las capas cambian el comportamiento del transistor.
Eso se traduce en diferencias reales en la frecuencia máxima estable, consumo de energía y calor. No lo “arreglas”; lo gestionas.
2) Test de oblea (wafer sort / probe test)
Antes de cortar los dados, equipos de prueba automatizados hacen probe a cada dado. Aquí se encuentran los defectos gruesos y se miden parámetros básicos.
El fabricante aprende qué dados están muertos, cuáles son marginales y cuáles son estelares. Esta etapa también es retroalimentación para el control del proceso:
si el borde de la oblea está consistentemente peor, lo verás de inmediato.
3) Corte, encapsulado y sus propias sorpresas
Tras el corte, un dado se encapsula: se sujeta, se cablea o bumpa, y se encierra. El encapsulado no es un paso neutral. Introduce nuevas
limitaciones: resistencia térmica, tensión mecánica y diferencias de integridad de señal. Un dado que parecía excelente en la oblea puede
comportarse de forma distinta una vez encapsulado y funcionando a voltajes reales con calor real.
4) Prueba final, burn-in (a veces) y asignación de SKU
La prueba final es donde se escribe la historia del SKU. El proveedor ejecuta patrones de prueba, valida bloques de funciones, comprueba fusibles y
verifica que la pieza cumple la especificación: objetivos de frecuencia, objetivos de potencia y requisitos funcionales. Luego recibe una etiqueta:
bin superior, bin medio, bin de “rescate” o descarte.
Esa es la versión de la línea de producción. La versión comercial es directa: el fabricante quiere maximizar el ingreso por oblea manteniendo
las tasas de fallo y los costos de garantía bajo control. El binning es cómo se atraviesa esa aguja.
Por qué los dados no son idénticos (y por qué te importa)
Si gestionas sistemas de producción, el binning importa por dos razones: variación y limitaciones.
Variación significa “misma SKU, comportamiento distinto”. Limitaciones significa “la especificación es un contrato, no una promesa de uniformidad”.
La variación de fabricación se convierte en variación de potencia, calor y boost
Los chips difieren en corriente de fuga. La fuga es consumo de energía que no realiza conmutaciones útiles. Más fuga significa más calor en reposo
y bajo carga, y menos margen para turbo/boost sin exceder límites de potencia. Dos CPUs pueden estar ambas “dentro de la spec” mientras una corre
más caliente y hace menos boost porque tiene más fuga.
Los márgenes se negocian entre voltaje, frecuencia y errores
El rendimiento que ves es el resultado de un acuerdo negociado entre la física y el firmware. Los proveedores establecen curvas voltaje-frecuencia,
límites de potencia y algoritmos de boost basados en la caracterización. Si un dado es marginal a alta frecuencia, o bien se clasifica en un bin más bajo
o se envía con límites conservadores. Si es excelente, puede venderse más alto o usarse para cumplir un SKU exigente de TDP/reloj. A veces es
el mismo silicio con un mapa de fusibles y configuración de firmware diferente.
Por qué esto importa en operaciones
En campo, el binning aparece como:
- Diferentes frecuencias sostenidas con todos los núcleos activados entre nodos “idénticos”.
- Trotado térmico en un subconjunto de hosts con el mismo diseño de refrigeración.
- Diferentes firmas de error: ECC corregido, machine checks corregidos o retrainings de enlace.
- Diferentes ratios “potencia a rendimiento” que arruinan la planificación de capacidad.
La meta del proveedor es enviar piezas que cumplan la especificación. Tu objetivo es operar una flota predecible. Esas metas se superponen, pero no
son la misma cosa.
El patrón de cinco niveles: cómo un dado se convierte en cinco SKUs
“Un dado se convierte en cinco niveles de precio” no es una ley literal; es un patrón recurrente. El número exacto varía, pero cinco es común
porque mapea bien a: buque insignia, alto, medio, bajo, salvamento. Así suele desarrollarse.
Tier 1: Bin insignia (la diapositiva de marketing)
Estos dados alcanzan la mejor combinación de alta frecuencia, baja fuga y comportamiento estable a voltajes objetivo. Pueden mantener
mayor boost dentro del mismo envelope de potencia y tienden menos a alcanzar límites térmicos en configuraciones típicas. El proveedor los
vende a precio premium porque el rendimiento es fácil de demostrar y los márgenes son atractivos.
Tier 2: Bin alto (todavía excelente, solo no titular)
Ligera peor fuga, ligera peor estabilidad a alta frecuencia, o un bloque de funciones que está bien pero no es ideal. Todavía habilitados
por completo, aún rápidos, pero puede requerir mayor voltaje para la misma frecuencia, lo que conlleva mayor potencia bajo carga. En servidores,
esto suele significar que hace boost, pero es más sensible a la refrigeración y a los límites de potencia.
Tier 3: Bin principal (donde vive el volumen)
Este es el centro de la distribución: cumple la spec cómodamente a relojes moderados. Suele ser el mejor valor por dinero porque está
ensamblado para volumen y tiene margen decente. Si compras para comportamiento de flota predecible, este tier suele comportarse mejor que
los bins extremos porque no está empujado cerca del límite.
Tier 4: Bin bajo (relojes más bajos, voltajes ajustados o funciones limitadas)
Estos dados quizá no mantienen altas frecuencias a voltajes razonables, o pueden ser más fugosos y violar límites de potencia a alta frecuencia.
La solución es sencilla: bajar frecuencias base/boost, limitar más la potencia o ambas. En algunas líneas de producto, este tier es también donde
se gestionan defectos menores deshabilitando un bloque (un núcleo, un slice de caché, una unidad compute de GPU).
Tier 5: Bin de salvamento (el montón “todavía útil”)
El salvamento es donde la economía del rendimiento se hace visible. Un dado puede tener un núcleo defectuoso, un segmento de caché fallido o una
línea de interconexión débil. Si el diseño permite redundancia o deshabilitar, el proveedor puede cortar con fusibles las partes malas y vender
el resto como una SKU de nivel inferior. El salvamento puede ser un producto perfectamente fiable cuando se hace correctamente. También puede
ser donde los márgenes son delgados y la validación más estricta—por eso quieres condiciones de operación conservadoras en producción.
Por eso “mismo dado” no significa “mismo chip”. El diseño del dado es un plano; el producto enviado es el plano más resultados de prueba más
configuración por fusible más política de firmware.
Broma #1: Si alguna vez te sientes inútil, recuerda que alguien validó una opción “modo gaming” que solo cambiaba el color RGB y la curva del ventilador.
Qué se mide durante el binning
Las pruebas varían por proveedor y producto, pero las dimensiones son consistentes. Si alguna vez te preguntaste por qué tu “TDP” no coincide
con la potencia tomada de la pared, o por qué el boosting es impredecible, es porque se están negociando múltiples restricciones a la vez.
Correctitud funcional
Primero: ¿funciona? Los proveedores ejecutan pruebas lógicas, cadenas de escaneo y self-tests incorporados. Si un bloque falla, o se descarta
o se deshabilita (si el producto lo permite para salvamento). En GPUs, deshabilitar unas pocas unidades de cómputo es un camino clásico de salvamento.
En CPUs suele ser núcleos o slices de caché, según la arquitectura.
Frecuencia según voltaje (curvas V/F)
La frecuencia máxima estable de un chip depende del voltaje y la temperatura. Los proveedores construyen tablas voltaje-frecuencia por pieza,
a veces con variación por núcleo. Mejor silicio logra mayor frecuencia a menor voltaje (o la misma frecuencia con menor potencia). Eso se convierte
en la base para los tiers de binning.
Fuga y potencia
La fuga varía ampliamente. Las piezas con alta fuga pueden cumplir objetivos de frecuencia pero exceder límites de potencia, lo que las hace
inadecuadas para SKUs de alto nivel. Los tiers inferiores pueden aceptar mayor fuga limitando relojes o vendiéndose a mercados con envelopes de potencia
menos estrictos.
Comportamiento térmico y sensibilidad a hotspots
Un dado con pobre comportamiento térmico puede alcanzar límites térmicos más pronto. La calidad del encapsulado y la aplicación de TIM también importan.
El binning no puede arreglar mágicamente un cooler débil, pero puede reducir la probabilidad de que un chip sea el outlier térmico que arruina tu flota uniforme.
Márgenes de la interfaz de memoria
El controlador de memoria integrado y el PHY son a menudo una dimensión de binning. Una pieza puede venderse con soporte para una velocidad de memoria más baja
o requerir márgenes de temporización más conservadores. En servidores, problemas de estabilidad de memoria son caros: la corrupción silenciosa de datos es
un evento que limita carrera profesional.
Interconexión y calidad de lanes I/O
PCIe y enlaces de alta velocidad tienen márgenes de integridad de señal. Los proveedores pueden certificar ciertas velocidades de enlace basadas en diagramas de ojo
o tasas de error medidas. Algunas piezas se binned a tasas de enlace más bajas o a menos lanes validadas.
Comportamiento de errores bajo estrés
Especialmente para piezas de servidor, las tasas de error corregidas bajo estrés pueden influir en el binning. La barra no es “cero errores corregidos para siempre.”
La barra es “dentro de límites aceptables para la carga de trabajo y modelo de garantía.” Tu barra puede ser más estricta, y eso está permitido.
Hechos interesantes y contexto histórico
- La gestión de rendimiento de fabricación precede a las CPUs modernas. La fabricación temprana aprendió rápido que vender solo dados perfectos hace la economía imposible.
- La clasificación por velocidad se hizo visible al consumidor en los 90. La idea de que el mismo diseño pudiera enviarse a distintas frecuencias se volvió mainstream con las CPUs de PC.
- “Harvesting” de bloques funcionales es un truco antiguo. Las memorias y CPUs han usado redundancia o fusibles para rescatar silicio parcialmente defectuoso desde hace mucho.
- Fusibles láser y eFuses hicieron la segmentación más fácil. Los chips modernos pueden configurarse permanentemente después de la fabricación, permitiendo diversidad de SKUs desde un mismo set de máscaras.
- Los dados en el borde de la oblea a menudo se comportan distinto. La variación del proceso a través de una oblea puede crear patrones espaciales; los datos de prueba se mapean rutinariamente para identificar problemas sistémicos.
- El encapsulado puede cambiar el bin. Un dado que pasa el probe de oblea puede fallar la prueba final tras el encapsulado por estrés, térmicas o cambios en integridad de señal.
- DRAM y NAND también se binned intensamente. Los proveedores de memoria binned por velocidad, latencia y tasas de error; los vendedores de SSD binned NAND por resistencia y rendimiento.
- Los SKUs de servidor suelen priorizar eficiencia energética sobre picos de reloj. Los datacenters pagan por vatios y refrigeración; un bin “más lento” puede ser un mejor producto operativo.
- Turbo/boost es efectivamente un binning dinámico en tiempo de ejecución. Las CPUs modernas deciden continuamente qué tan cerca del borde pueden operar dadas temperatura, potencia y carga.
Tres micro-historias corporativas desde las trincheras
Micro-historia 1: El incidente causado por una suposición errónea (SKU = comportamiento)
Una empresa desplegó un nuevo lote de nodos de cómputo para un servicio sensible a latencia. Compraron “bien”: mismo proveedor,
mismo número de modelo, mismo stepping (tal como pudieron verificar), mismos ajustes de BIOS, misma disposición de rack. Aun así, el servicio desarrolló
un extraño problema de cola de latencia que apareció sólo durante picos regionales de tráfico.
El equipo on-call persiguió los sospechosos habituales: pausas de GC, vecinos ruidosos, regresiones del scheduler del kernel. Nada encajaba. Las métricas mostraron
que un subconjunto de hosts corría unos grados más caliente y sostenía una frecuencia all-core ligeramente más baja bajo carga máxima. No suficiente para disparar
alertas. Suficiente para estirar p99.
La suposición errónea fue sutil: “misma SKU implica mismo rendimiento sostenido.” Lo que en realidad tenían eran múltiples bins de silicio
bajo la misma etiqueta de SKU por realidades de la cadena de suministro. Dentro de la spec, sí. Uniforme, no. Bajo la política de capado de potencia del servicio,
las piezas más fugosas alcanzaban los límites de potencia antes y reducían el boost, convirtiéndolas en outliers consistentes de cola.
La solución no fue exótica. Crearon un paso de burn-in y caracterización para nuevos nodos, registrando frecuencia sostenida bajo una carga estandarizada,
junto con potencia y temperatura. Los nodos que caían en el clúster “caliente/bajo” se asignaron a cargas por lotes, no a pools críticos de latencia. Misma SKU.
Destinos distintos. La producción se tranquilizó.
Micro-historia 2: La optimización que salió mal (ajuste de potencia encuentra la lotería del silicio)
Otra organización quiso reducir costes de energía. Aplicaron undervolting agresivo y apretaron límites de potencia en una flota,
basándose en pruebas de laboratorio de unas pocas máquinas representativas. Los benchmarks se vieron bien: menos vatios, casi el mismo rendimiento,
y una bonita presentación para el liderazgo.
En producción, el cambio se comportó como un desastre educado. Una fracción de nodos empezó a mostrar errores de machine check corregidos bajo
carga. Luego una fracción menor escaló a errores no corregidos y reinicios espontáneos—raro, pero siempre durante las peores horas posibles. El impacto
en el nivel de servicio fue pequeño pero recurrente, que es el tipo de modo de fallo que desgasta a los equipos durante meses.
El mecanismo del reves: el undervolt redujo el margen de ruido en silicio marginal. Las unidades de laboratorio eran mejores bins; la flota tenía
una distribución que incluía dados más débiles. Los errores eran “corregidos” hasta que dejaron de serlo, y la telemetría de error al principio se ignoró
porque “corregido” sonaba a “está bien”.
El equipo revirtió el undervolt, mantuvo una reducción de límite de potencia moderada y añadió un guardrail: cualquier nodo con tasa de errores corregidos
por encima de un umbral se retiraba automáticamente del pool y se probaba. Eventualmente reintrodujeron afinación por nodo usando estabilidad medida,
no deseos.
Micro-historia 3: La práctica aburrida pero correcta que salvó el día (la higiene de flota gana)
Un servicio con mucha carga de almacenamiento corría workloads mixtos: compactación, cifrado y streaming de alto throughput. Estandarizaron en una SKU de CPU
por simplicidad. Pero hicieron una cosa aburrida con consistencia: registraban modelo de CPU, versión de microcode, ajustes de BIOS de potencia y telemetría
de machine-check en su sistema de inventario, y nunca se saltaban las pruebas de burn-in para racks nuevos.
Meses después, llegó un nuevo envío durante una escasez de suministro. Misma SKU en papel, pero el comportamiento bajo carga era ligeramente distinto:
consumo de potencia mayor y boost menos estable. La diferencia estaba dentro de la spec, pero importaba para su envelope térmico.
Como tenían líneas base, detectaron el cambio el primer día. No culparon a la aplicación. No culparon al kernel. Correlacionaron el cambio con lotes de fabricación
y ajustes de firmware, luego actualizaron la colocación en rack y las curvas de ventilador para esa cohorte. El despliegue continuó sin alcanzar umbrales de trote térmico.
Nadie fue ascendido por “notar un cambio de distribución y ajustar políticas”. Pero nadie recibió un page a las 3 a.m. tampoco. Ese es el tipo correcto de aburrido.
Tareas prácticas: comandos, salidas y decisiones
No puedes “ver los bins” directamente sin datos de prueba del proveedor, pero puedes observar las consecuencias: comportamiento de frecuencia, límites de potencia,
margen térmico y tasas de error. Abajo hay tareas prácticas que puedes ejecutar en servidores Linux para caracterizar y gestionar la varianza causada por binning.
Cada una incluye: un comando, salida de ejemplo, qué significa y qué decisión tomar.
Task 1: Identificar modelo de CPU, stepping y microcode
cr0x@server:~$ lscpu | egrep 'Model name|Stepping|CPU\(s\)|Thread|Socket|Vendor|MHz'
Vendor ID: GenuineIntel
Model name: Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU(s): 64
Thread(s) per core: 2
Socket(s): 2
Stepping: 6
CPU MHz: 2000.000
Significado de la salida: Confirma lo que crees que compraste y si existen múltiples steppings en la flota.
Decisión: Si ves steppings mixtos o modelos inesperados bajo la misma orden de compra, separa pools y establéalos por separado.
Task 2: Ver versión de microcode y si las actualizaciones están en efecto
cr0x@server:~$ grep -m1 microcode /proc/cpuinfo
microcode : 0x2d
Significado de la salida: El microcode impacta comportamiento de boost y márgenes de estabilidad. Versiones distintas pueden cambiar rendimiento y tasas de error.
Decisión: Estandariza el microcode en la flota antes de comparar “comportamiento por bin”. Si no, estarás comparando manzanas con firmware.
Task 3: Ver la política actual del governor de CPU
cr0x@server:~$ cpupower frequency-info | sed -n '1,18p'
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: Cannot determine or is not supported.
hardware limits: 800 MHz - 3500 MHz
available cpufreq governors: performance powersave
current policy: frequency should be within 800 MHz and 3500 MHz.
The governor "powersave" may decide which speed to use
current CPU frequency: 1200 MHz (asserted by call to hardware)
Significado de la salida: Muestra si el sistema puede hacer boost o está limitado por política.
Decisión: Para ejecuciones de caracterización, usa un governor consistente (a menudo performance) para reducir ruido al comparar nodos.
Task 4: Fijar el governor en performance para una prueba controlada
cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Significado de la salida: El governor cambió. La máquina favorecerá frecuencias más altas.
Decisión: Si tu flota depende de governors de ahorro de energía, no cambies los valores por defecto en producción globalmente; usa esto solo durante pruebas o en pools dedicados.
Task 5: Observar frecuencias por núcleo bajo carga (chequeo rápido de la realidad)
cr0x@server:~$ sudo turbostat --quiet --show CPU,Avg_MHz,Busy%,Bzy_MHz,PkgWatt,PkgTmp --interval 2 --num_iterations 3
CPU Avg_MHz Busy% Bzy_MHz PkgWatt PkgTmp
- 2860 92.3 3099 182.40 78
- 2795 93.1 3003 179.10 80
- 2712 94.0 2886 176.85 82
Significado de la salida: Bzy_MHz baja a medida que la temperatura sube; la potencia queda cerca de un tope.
Decisión: Si Bzy_MHz sostenida difiere notablemente entre nodos “idénticos”, trátalos como bins de rendimiento distintos para la programación.
Task 6: Ver trote térmico y sensores de temperatura
cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +82.0°C (high = +90.0°C, crit = +100.0°C)
Core 0: +79.0°C (high = +90.0°C, crit = +100.0°C)
Core 1: +80.0°C (high = +90.0°C, crit = +100.0°C)
Significado de la salida: Estás cerca de umbrales “altos”; pequeñas diferencias de bin pueden voltearte al trote térmico.
Decisión: Si una cohorte corre consistentemente más caliente, ajusta curvas de ventilador, colocación en rack o asignación de carga antes de culpar a la aplicación.
Task 7: Inspeccionar logs del kernel por machine-check y errores de hardware corregidos
cr0x@server:~$ sudo journalctl -k -b | egrep -i 'mce|machine check|edac|hardware error' | tail -n 8
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: CPU 17: Machine Check: 0 Bank 7: b200000000070005
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: TSC 0 ADDR fef1a140 MISC d012000100000000
Jan 12 02:14:03 server kernel: mce: [Hardware Error]: PROCESSOR 0:50656 TIME 1705025643 SOCKET 0 APIC 34 microcode 2d
Significado de la salida: Existen errores de hardware. Incluso si están “corregidos”, son un indicador principal de condiciones marginales de voltaje/frecuencia/térmicas.
Decisión: Cuarentena nodos con errores corregidos recurrentes; investiga refrigeración, microcode y cualquier ajuste de undervolt/potencia.
Task 8: Revisar contadores EDAC (ECC de memoria)
cr0x@server:~$ sudo edac-util -v
mc0: 2 Uncorrected Errors with no DIMM info
mc0: 37 Corrected Errors with no DIMM info
Significado de la salida: Están ocurriendo errores corregidos; los errores no corregidos son una sirena de paginación.
Decisión: Brotes de errores corregidos sugieren margen de temporización marginal o un DIMM degradado; programa reemplazo y valida la política de velocidad de memoria para esa cohorte de CPU.
Task 9: Confirmar la velocidad de memoria real (y si está reducida)
cr0x@server:~$ sudo dmidecode -t memory | egrep 'Speed:|Configured Memory Speed:' | head -n 10
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Significado de la salida: Los DIMMs soportan 3200, pero la plataforma los ejecuta a 2933 (puede ser límites del IMC de la CPU, reglas de población o BIOS).
Decisión: Si un lote nuevo está silenciosamente corriendo a menor velocidad de memoria, vuelve a revisar restricciones de stepping/bin de CPU y reglas de población del BIOS; ajusta expectativas y planes de capacidad.
Task 10: Medir límites de potencia del package (causa común de “¿por qué no hace boost?”)
cr0x@server:~$ sudo rdmsr -a 0x610 | head -n 4
00000000f8c800f8
00000000f8c800f8
00000000f8c800f8
00000000f8c800f8
Significado de la salida: Valor crudo de MSR codificando límites de potencia (PL1/PL2) en algunas plataformas Intel.
Decisión: Si diferentes cohortes muestran diferentes ajustes de PL, estandariza la política de potencia del BIOS o separa pools; no compares rendimiento hasta que los límites coincidan.
Task 11: Confirmar límites de frecuencia de CPU expuestos al OS
cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
3500000
Significado de la salida: Frecuencia máxima en kHz. Si es menor de lo esperado, puedes estar limitado por BIOS, política de potencia o un modo de restricción térmica.
Decisión: Si esto difiere entre nodos de la misma SKU, trátalo como deriva de configuración.
Task 12: Prueba de estrés para comportamiento sostenido (no solo turbo de ráfaga)
cr0x@server:~$ stress-ng --cpu 0 --cpu-method matrixprod --timeout 60s --metrics-brief
stress-ng: info: [22118] setting to a 60 second run per stressor
stress-ng: metrc: [22118] stressor bogo ops real time usr time sys time bogo ops/s
stress-ng: metrc: [22118] cpu 6823 60.02 59.81 0.11 113.7
Significado de la salida: Un proxy rápido de rendimiento. Úsalo con turbostat para ver potencia/trote térmico.
Decisión: Si el rendimiento diverge significativamente entre nodos con las mismas configuraciones, crea un mapa de cohortes y programa en consecuencia.
Task 13: Inspeccionar estado del enlace PCIe (el margen I/O puede parecer “almacenamiento lento”)
cr0x@server:~$ sudo lspci -vv -s 3b:00.0 | egrep 'LnkCap:|LnkSta:'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x16 (ok)
Significado de la salida: El enlace se entrenó a 8GT/s. Eso puede ser integridad de señal, BIOS o un lane marginal.
Decisión: Si una cohorte hace downtrain consistentemente, no “optimices” software. Arregla cableado, elección de slot, firmware o RMA del host si persiste.
Task 14: Confirmar topología NUMA y localidad de memoria (binning se encuentra con la topología)
cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
node 0 size: 257642 MB
node 0 free: 192110 MB
node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
node 1 size: 257919 MB
node 1 free: 198844 MB
Significado de la salida: Dos nodos NUMA. Mala colocación puede imitar rendimiento de “mal bin”.
Decisión: Si solo algunos hosts parecen lentos, verifica pinning NUMA y localidad de memoria antes de culpar al silicio.
Task 15: Revisar throttling por cgroup (no culpes al chip por tus límites)
cr0x@server:~$ cat /sys/fs/cgroup/cpu.stat
usage_usec 912345678
user_usec 900000000
system_usec 12345678
nr_periods 56012
nr_throttled 8421
throttled_usec 98765432
Significado de la salida: La carga está siendo throttled por cuotas de cgroup.
Decisión: Si ves throttling, arregla límites de recursos o scheduling primero; de lo contrario atribuirás la variación de rendimiento al binning incorrectamente.
Task 16: Detectar “clústeres de bin” a nivel de flota mediante comparación simple
cr0x@server:~$ awk -F: '/model name/ {m=$2} /microcode/ {u=$2} END {gsub(/^[ \t]+/,"",m); gsub(/^[ \t]+/,"",u); print m " | microcode " u}' /proc/cpuinfo
Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz | microcode 0x2d
Significado de la salida: Un dato de inventario barato que puedes recolectar en todas partes.
Decisión: Combínalo con líneas base de potencia/temp/rendimiento. Si ves múltiples cohortes de microcode, alinéalas antes de sacar conclusiones sobre diferencias de bin.
Broma #2: Tu modelo de capacidad es “determinista” hasta que conoces al único servidor que hace boost como si pagara la renta por vatio.
Guía rápida de diagnóstico
Cuando un subconjunto de nodos es más lento/más caliente/menos fiable y sospechas efectos de “binning”, necesitas una forma rápida de encontrar el cuello de botella real.
Aquí está la guía que uso.
Primero: elimina deriva de configuración y límites artificiales
- Governor/política: confirma que
cpupower frequency-infoes consistente. - Límites de potencia: revisa ajustes del BIOS (y si está disponible, telemetría de límites de potencia).
- Política térmica: asegúrate de que curvas de ventilador y flujo de aire sean idénticos; busca polvo y blank panels bloqueados.
- Throttling por cgroup: verifica que no estés aplicando cuotas CPU distintas a los nodos “lentos”.
Segundo: revisa térmicas y potencia bajo carga sostenida
- Ejecuta una carga controlada de 5–10 minutos (p. ej.,
stress-ng). - Captura
turbostatparaBzy_MHz,PkgWattyPkgTmp. - Compara cohortes. Si la potencia alcanza un techo mientras la frecuencia baja, estás limitado por potencia. Si la temperatura alcanza “alto”, estás limitado térmicamente.
Tercero: busca errores corregidos y downtraining de I/O
- MCE/EDAC corregidos: errores corregidos recurrentes no son “están bien”, son “pre-fallo”.
- Velocidad de enlace PCIe: el downtraining puede reducir a la mitad el ancho de banda I/O y parecer una regresión de almacenamiento/red.
- Velocidad de memoria: confirma que la velocidad configurada de memoria no bajó en un lote nuevo.
Cuarto: toma una decisión rápida
- Si es configuración: corrige la deriva y re-establece las líneas base.
- Si es térmico: ajusta flujo de aire, colocación o deriva esa cohorte.
- Si es estabilidad marginal: retira de pools sensibles y contacta soporte/RMA del proveedor.
- Si es variación normal de bin: programa inteligentemente; deja de fingir que la flota es homogénea.
Errores comunes: síntoma → causa raíz → solución
1) Síntoma: “Misma SKU, pero algunos nodos son 5–10% más lentos bajo carga”
Causa raíz: diferencias en límites de potencia, diferencias en margen térmico, o variación de fuga por bin interactuando con tus caps de potencia.
Solución: estandariza la política de potencia del BIOS; establece línea base con turbostat; agrupa nodos por frecuencia/potencia sostenida; programa trabajo crítico de latencia al mejor cohort.
2) Síntoma: “Tras undervolting, aparecen errores corregidos, luego reinicios ocasionales”
Causa raíz: el undervolt eliminó margen de ruido; los bins más débiles fallan primero.
Solución: revierte el undervolt; reintrodúcelo solo con calificación por nodo y guardarraíles de tasa de error; trata los errores corregidos como telemetría accionable.
3) Síntoma: “Lote nuevo corre más caliente, ventiladores más ruidosos, pero rendimiento igual o peor”
Causa raíz: cohorte de silicio más fugosa o variación de encapsulado; misma spec, eficiencia distinta.
Solución: compara PkgWatt y PkgTmp bajo carga controlada; ajusta colocación en rack, flujo de aire y asignación de pools para la nueva cohorte.
4) Síntoma: “Rendimiento de almacenamiento cayó; CPU parece inactiva”
Causa raíz: enlace PCIe hizo downtrain (margen de integridad de señal), o firmware cambió la política de enlace.
Solución: verifica con lspci -vv; vuelve a asentar tarjetas, comprueba risers/cables, actualiza firmware y aisla cohorte; RMA si persiste.
5) Síntoma: “Ráfagas de benchmark se ven geniales, carga sostenida en producción se ve mal”
Causa raíz: el comportamiento turbo enmascara trote sostenido por límites de potencia/térmicos.
Solución: prueba sostenida (minutos, no segundos) mientras registras turbostat y temperaturas; afina para comportamiento sostenido, no para números de boost de marketing.
6) Síntoma: “Solo un subconjunto de nodos muestra errores ECC corregidos”
Causa raíz: diferencias de margen en la interfaz de memoria, envejecimiento de DIMMs o diferencias en el entrenamiento de memoria del BIOS interactuando con una cohorte de silicio.
Solución: valida la velocidad de memoria configurada, ejecuta diagnósticos de memoria, intercambia DIMMs entre nodos para aislar plataforma vs DIMM, y mantén ajustes conservadores de memoria para esa cohorte.
7) Síntoma: “Los gráficos de rendimiento parecen un peine: algunos nodos consistentemente arriba, otros consistentemente abajo”
Causa raíz: tienes múltiples bins efectivos en el mismo pool.
Solución: deja de balancear carga a ciegas; añade scoring de nodos basado en rendimiento sostenido/watt y telemetría de errores; particiona pools por cohorte.
Listas de verificación / plan paso a paso
Plan paso a paso: convertir el binning del caos en hechos de inventario
- Recolecta identidad de hardware consistentemente. Modelo, stepping, microcode, versión de BIOS, configuración de memoria, topología NIC/PCIe.
- Define un perfil estándar de burn-in. Una carga sostenida de CPU, una carga de memoria y una comprobación de sanidad I/O. Mantenlo aburrido y repetible.
- Captura tres métricas por nodo: frecuencia sostenida all-core, potencia del package y temperatura máxima durante la ventana de burn-in.
- Registra contadores de errores corregidos. MCE y EDAC. Rastrea deltas, no solo valores absolutos.
- Agrupa nodos en cohortes. No por sensaciones—por comportamiento medido.
- Asigna cargas según características de cohorte. Sensibles a latencia en cohortes frías/eficientes; batch en cohortes calientes/fugosas.
- Establece guardarraíles. Cualquier nodo que supere umbrales de errores corregidos sale automáticamente del pool.
- Estandariza firmware. Ajustes de BIOS y microcode deben ser consistentes antes de comparar cohortes en el tiempo.
- Comunica la realidad de compras. “Misma SKU” no garantiza rendimiento sostenido idéntico. Haz que eso sea una suposición escrita en la planificación de capacidad.
- Revisa trimestralmente. Las distribuciones de silicio cambian entre lotes de fabricación; el comportamiento de tu flota derivará a menos que sigas midiendo.
Lista de hacer/no hacer (edición ops)
- Hacer: medir el comportamiento sostenido bajo tu política real de potencia. Evitar: confiar en una ráfaga de benchmark de 30 segundos.
- Hacer: tratar los errores corregidos de hardware como señal. Evitar: esperar a errores no corregidos para “probar” un problema.
- Hacer: separar cohortes cuando sea necesario. Evitar: forzar un modelo de scheduling homogéneo sobre silicio heterogéneo.
- Hacer: mantener ajustes conservadores para tiers con mucho salvamento. Evitar: aplicar undervolts agresivos a toda la flota.
Preguntas frecuentes
1) ¿El binning es solo una forma de cobrar más por el mismo chip?
En parte. También es la forma en que los fabricantes venden más de cada oblea. Sin binning, descartarías mucho silicio que es perfectamente utilizable
a un reloj más bajo o con un bloque deshabilitado. El precio sigue al rendimiento y la demanda, pero el motor subyacente es la economía del yield.
2) ¿Los bins de mayor nivel son siempre más fiables?
No automáticamente. Las piezas de nivel superior pueden operar más cerca de los bordes de rendimiento (relojes más altos, mayor densidad de potencia), lo que puede estresar
la refrigeración y la entrega de energía. La fiabilidad es una propiedad del sistema: silicio + firmware + placa + refrigeración + carga.
3) ¿Por qué dos CPUs con el mismo número de modelo hacen boost de forma distinta?
Porque el boost está condicionado por potencia, temperatura y características del silicio como la fuga. Incluso dentro de una SKU, las piezas pueden tener distintas curvas V/F.
Añade diferencias de BIOS, microcode y variación de refrigeración, y la “misma” CPU se convierte en una distribución.
4) ¿El silicio de salvamento es “malo”?
No necesariamente. Salvamento significa “se deshabilitaron algunos bloques”. Los bloques restantes pueden ser perfectamente fiables si se validan correctamente.
Pero debes asumir menos margen y ser conservador con undervolting, overclocking de memoria y envelopes térmicos ajustados.
5) ¿Puedo detectar mi bin exacto como usuario final?
Usualmente no. Los proveedores no exponen identidades de bin directamente. Puedes inferir comportamiento: frecuencia sostenida a un límite de potencia dado,
requisitos de voltaje, térmicas y tasas de error. Para operaciones, la inferencia es suficiente para tomar decisiones de programación y compra.
6) ¿La “lotería del silicio” es real o solo folklore de internet?
La variación es real. La parte folclórica es creer que puedes “ganar” consistentemente con tácticas de consumidor. En producción, no apuestas; mides, agrupas y programas.
Apostar tus SLOs a probabilidades de lotería es una elección profesional extraña.
7) ¿Cómo se relaciona el binning con el TDP?
El TDP es un objetivo de diseño térmico/potencia, no una promesa de consumo en la pared. El binning decide qué silicio puede alcanzar un determinado nivel de rendimiento
dentro de un envelope TDP. Los algoritmos de boost en tiempo de ejecución luego trabajan dentro de (y a veces alrededor de) esos límites.
8) ¿El microcode afecta al binning?
El binning se hace en la fabricación, pero el microcode afecta cuán agresivamente la CPU usa sus márgenes en el campo. Las actualizaciones pueden cambiar política de boost,
mitigar erratas y alterar rendimiento. Si comparas cohortes, alinea el microcode primero.
9) ¿Por qué un proveedor enviaría el mismo dado con funciones deshabilitadas en vez de fabricar un dado más pequeño?
Los sets de máscaras son caros, la validación es costosa y el time-to-market es implacable. Enviar un diseño de dado y segmentarlo vía fusibles reduce complejidad y mejora la economía del yield.
Dados más pequeños pueden venir después como derivados optimizados en coste.
10) ¿Cuál es la mejor respuesta operativa al binning y su variación?
Trata el hardware como tratas las redes: mide, modela distribuciones y construye guardarraíles. Usa líneas base de burn-in, scheduling consciente de cohortes y umbrales de telemetría de errores.
No asumas uniformidad porque compras hicieron un buen trabajo.
Conclusión: próximos pasos que realmente ayudan
El binning es cómo la fabricación convierte la realidad imperfecta en productos enviables. Un diseño de dado se convierte en cinco niveles de precio porque
es la única forma sensata de obtener yield, segmentación de rendimiento y fiabilidad dentro de un presupuesto de garantía. Para los operadores, la conclusión no es
“el proveedor es malvado”. La conclusión es: tu flota es una distribución, y fingir lo contrario te hace más lento,
más caliente y más sorprendido.
Los próximos pasos prácticos:
- Empieza a recolectar stepping de CPU, microcode y ajustes de BIOS en el inventario.
- Añade un breve burn-in repetible que capture frecuencia sostenida, potencia y temperatura.
- Rastrea errores de hardware corregidos y pon en cuarentena automáticamente a los reincidentes.
- Agrupa nodos en cohortes y programa cargas en consecuencia.
- Estandariza firmware antes de declarar un “problema de binning”.
Idea parafraseada de Werner Vogels: “Todo falla, todo el tiempo—diseña y opera como si eso fuera normal.”