Estoy haciendo un pequeño dispositivo móvil con Raspberry Pi que depende de las baterías, por lo que el consumo de energía es un problema. He escalado el "arm_freq_min" (no estoy seguro de si el reloj o la frecuencia del ciclo de instrucciones) es mucho más bajo que la frecuencia predeterminada en aproximadamente un factor de 10. He oído que \ $ \ textrm {Power} \ propto fV ^ 2 + P_ {base } \ $, pero ¿cuándo se rompe esta linealidad entre potencia y frecuencia?
Tenga en cuenta que hay dos unidades involucradas aquí:
El requisito de potencia total de una CPU está básicamente influenciado por las siguientes partes:
Básicamente, cada 'interruptor' (transistor) dentro de una CPU consumirá una cierta cantidad constante de energía cada vez que cambie (para una tensión de alimentación determinada).
Cuanto más alta es la frecuencia de reloj, más "conmutación" se puede hacer por unidad de tiempo . Más "cambio" también significa que se pueden hacer más cálculos por unidad de tiempo . Por lo tanto, realizar un cálculo dado siempre consumirá la misma cantidad de energía, independientemente de la frecuencia del reloj: doble frecuencia = doble consumo de energía durante la mitad del tiempo.
Entonces, la pregunta en realidad es: ¿Qué determina el consumo de energía cuando el cálculo no se realiza en un momento dado?
La mayoría de las CPU tienen funciones de ahorro de energía que les permiten detener la operación (de los submódulos) por completo por algún tiempo. El núcleo de la CPU en sí, que realiza la obtención de instrucciones, la decodificación, & c. se puede detener completamente cuando no hay nada que hacer, básicamente reduciendo el consumo de esta parte en algunos órdenes de magnitud.
Teóricamente, el consumo de una CPU se puede reducir a casi cero en los momentos en que simplemente se queda esperando a que "algo" haga. Este es principalmente el caso cuando la CPU tiene que esperar datos de otros componentes, como la tarjeta SD, que no puede entregar los datos tan rápido como la CPU podría procesarlos.
Aquí, el software, el sistema operativo y las aplicaciones entran en juego.
El sistema operativo debería (y generalmente lo hace) "hace una pausa" en la CPU cuando actualmente no hay ninguna tarea lista para realizar algún cálculo. La consistencia con la que se haga esto está sujeta a algunos compromisos inevitables que se requieren al crear un sistema operativo.
Además, las aplicaciones (tareas) deben ser 'cooperativas' w.r.t. El sistema operativo le permite activar el modo de ahorro de energía. "Espera ocupada" en un bucle en una aplicación, aunque básicamente no hace nada útil, usará cantidades significativas de energía (y energía), y el sistema operativo no tiene medios para detectar que en realidad podría simplemente detenerse la CPU.
Dicho esto, debe quedar claro que los límites de la frecuencia de reloj que uno puede configurar nunca están garantizados para tener ningún efecto de una manera u otra. - Al igual que una memoria caché no está garantizada para acelerar el proceso. Sin embargo, en la práctica, por lo general lo hace.
Por lo tanto, en teoría, el consumo total de energía (para una tarea determinada) no está influenciado por la frecuencia. Sin embargo, el requisito de potencia de pico depende linealmente de la frecuencia. (Recuerda que cada "cambio" toma la misma cantidad de energía ).
En la práctica, debido en parte a compromisos en el software, su millaje puede variar. Especialmente cuando se realiza un escalado de reloj dinámico y basado en la demanda, como suele hacer el sistema operativo en el "RPi".
Entonces, en teoría, la relación entre la demanda de potencia y la frecuencia es puramente lineal en todas las frecuencias. En la práctica, uno puede razonablemente esperar ahorrar energía con velocidades de reloj más bajas, pero no está garantizado y en un sistema complejo de hardware y software probablemente ni siquiera sea casi lineal.
Lea otras preguntas en las etiquetas power frequency raspberry-pi