El CPPC2 es el elemento que controla las variaciones de frecuencia de las CPU de AMD bajo sus arquitecturas Zen. En este artículo os explicaremos cómo funciona esta tecnología en los procesadores y APU Ryzen y en qué se diferencia de otros sistemas de variación en la velocidad de reloj de un procesador según su estado de consumo.
Las noticias de la pérdida de rendimiento de los procesadores Ryzen de AMD al ejecutar Windows 11 durante las primeras semanas de vida del sistema operativo de Microsoft apareció con una palabra totalmente críptica, CPPC2. ¿Qué significan y que relación tienen con los procesadores de la marca?
¿Qué es el CPPC2 en las CPU de AMD?
Una de las particularidades que tienen todos los procesadores de PC es la capacidad de variar su velocidad de reloj según el estado de consumo en el que este se encuentre. Tradicionalmente, esto se hacía teniendo en cuenta los estados P del estándar de la ACPI, pero AMD desde en sus arquitecturas Zen añadió el llamado CPPC2 como método para cambiar la velocidad de reloj del llamado «núcleo preferencial», el cual es aquel que puede alcanzar en solitario velocidades de reloj más altas pese a que es arquitecturalmente simétrico al resto de sus hermanos.
La particularidad del CPPC2 es a la hora de cambiar la velocidad de reloj al pasar de un estado a otro, ya que bajo los llamados P-States pasar de un estado de consumo a otro y, por tanto, variar la velocidad de reloj supone una espera de 30 milisegundos, mientras que con el nuevo paradigma con los Zen de AMD supone que dicho cambio se realiza en 1 o 2 milisegundos de tiempo.
El CPPC2 también supone darle el control total sobre la migración de una velocidad a otra al procesador y no por el sistema operativo. Lo cual supone que se utilizarán los sensores de temperatura, voltaje y velocidad de reloj dentro del mismo procesador. Todos ellos gestionados por la llamada System Management Unit es una pieza que se encarga de monitorizar dichas variables.
Ampliando sobre el núcleo preferencial
Hemos de partir de la idea que pese a que el CPPC2 reemplazan los P-States no son más que una versión mejorada del mismo. En realidad la definición de núcleo preferencial viene definida por la sección 8.4.7 del documento estándar de la ACPI, donde podemos leer lo siguiente:
Anteriormente, los controles de rendimiento del procesador (P-States y T-States) describían su efecto sobre el rendimiento de un procesador en términos de la frecuencia, donde esta es una aproximación de la velocidad en la que un procesador completa una tarea. No obstante, el rendimiento por carga de trabajo no garantiza que escale con frecuencia. Por lo tanto, en vez de prescribir una métrica específica para el rendimiento del procesador, el Collaborative Processor Performance Control le deja la definición de dicha métrica a la plataforma. Por lo que la plataforma puede escoger una simple métrica como la frecuencia o carias de ellas para crear una métrica de rendimiento.
Esto tiene una explicación muy simple, entendamos que cada instrucción a ejecutar es una carga de trabajo, pues bien, no todas suponen el mismo consumo energético, habrá instrucciones que necesiten más energía y otras que menos. AMD con la implementación de su tecnología SmartShift ha optado por un entorno basado en el consumo por instrucción, esto les permite acelerar a una gran velocidad las partes del código compuestas mayoritariamente por instrucciones más sencillas, lo que supone una disminución del tiempo de ejecución de los procesos y con ello un aumento considerable del IPC.
CPPC2 y su relación con el sistema operativo
Una de las tareas que ejecuta un sistema operativo es la asignación de los centenares de procesos a los diferentes núcleos del procesador, por lo que este ha de estar informado en cada momento de cuáles de ellos tienen mayor rendimiento en cada momento para poder distribuir las diferentes tareas de manera eficiente y que los programas se puedan ejecutar de forma eficiente.
Es aquí donde entra una pequeña confusión por parte de AMD, ya que la SMU informa aplicaciones como el Ryzen Master del que es el mejor procesador en cuanto a condiciones de potencia, los cuales normalmente suelen ser los núcleos marcados como 0 y 1. En cambio, el CPPC2 tiene el concepto de núcleo preferencial, el cual si bien coincide con la definición de mejor núcleo tiene una excepción muy clara. Con tal de evitar la sobresaturación en modo de una cola de trabajo muy grande el sistema puede asignar al vuelo como núcleo favorito uno que no esté haciendo nada. Esto tiene sentido con tal de reducir la latencia acumulada.
Esta pequeña diferencia provoca ciertos problemas, como el que le ocurrió a Windows 11, donde las rotaciones de núcleo del CPPC2 suponían una pérdida de rendimiento por la mala asignación de procesos sobre los núcleos. Algo que AMD soluciono a partir del driver 3.10.08.506 o posterior para que los procesos se ejecuten en los núcleos adecuados, mejorando el rendimiento general de todo el sistema.
Los datos se encuentran en el firmware del procesador
En cada modelo de procesador se incluye un pequeño firmware interno, el cual informa de las especificaciones del mismo, pero también cuáles son los núcleos que pueden alcanzar la velocidad de reloj más alta. Por lo que la pregunta del sistema operativo sobre cuál de ellos es más rápido no es dada por el CPPC2, sino por el firmware integrado en la CPU.
De lo que se encarga el CPPC2 es controlar la velocidad de reloj de los diferentes núcleos Ryzen según los diversos estados de consumo. Por lo que cuando tanto el sistema operativo como las diferentes aplicaciones para el overclock eligen el mejor núcleo de las CPU o APU Ryzen lo que hacen es tomar la información del firmware. Lo que ocurre es que si tenemos el CPPC2 activo a través de la BIOS UEFI entonces el sistema operativo no pregunta al SMU para permitir la rotación de núcleos que os hemos descrito con anterioridad.
El motivo por el cual el sistema operativo ha de preguntar al CPPC2 sobre el mejor núcleo posible es por el hecho que por motivos de seguridad sería totalmente contraproducente que cualquier software, incluido SO, tenga acceso a la información guardada dentro de la CPU. No olvidemos por ejemplo que el fTPM guarda una serie de claves privadas del usuario en el firmware.
