Consumo de energía de Raspberry Pi Zero 2 W

Cuando completé mi análisis de Raspberry Pi Zero 2 W, mencioné que probaría el consumo de energía de la placa más tarde. Me tomó un tiempo, pero finalmente lo resolví usando Otii Arc de Qoitech y software Otii para proporcionar algunos gráficos bonitos de consumo de energía, e incluso el consumo de energía. Dado que la Fundación Raspberry Pi recomienda una fuente de alimentación de 5V/2.5A, primero intentaré acercarme lo más posible a 2.5A, luego seguiré algunos trucos para reducir el consumo de energía inactivo a menos de 75 mA/375 mW, y finalmente verifique el consumo de energía en varios recuentos y frecuencias de núcleos de CPU.

Raspberry Pi Zero 2 W Consumo de energía bajo carga, con accesorios

Comencé con la última imagen «Bullseye» de Raspberry Pi OS Lite y conecté mi placa Raspberry Pi Zero 2 W a las herramientas Qoitech Otii Arc como se muestra a continuación. Solía ​​costar alrededor de $ 500, pero ahora el precio comienza en $ 699, y es una gran herramienta para las personas que desarrollan dispositivos a batería, y admito que es un poco exagerado, pero el propósito de esta publicación, pero aún funciona. .

Encienda la Raspberry Pi y verifiquemos el consumo de energía inactivo usando la imagen que acabamos de mostrar sin ninguna modificación.

Eso es aproximadamente 120 mA a 5V o 600 mW. Si ha visto números más bajos con revisiones anteriores de Raspberry Pi Zero 2 W, es porque estamos usando la imagen de Raspberry Pi OS Bullseye en lugar de la imagen de Buster, y explicaremos la razón por la cual es más adelante en esta publicación.

También tengo una Raspberry Pi Zero (sin WiFi) y consume 108 mA con la misma imagen.

Otra característica interesante del Otii Arc es la sincronización de los datos de medición de potencia con la consola en serie, así que conecté los cables para acceder a la consola en serie en el programa Otii.

También habilité UART en config.txt:

y SSH creando un archivo /boot/ssh vacío en la tarjeta microSD. Esto se debe a que la consola en serie en Otii no es muy conveniente de usar, no hay historial, se pueden ejecutar programas como vim o raspbi-config, etc. Salida de consola serial con datos V/A. El consumo de energía subió a 125 mA después de eso.

Probé USB Ethernet, WiFi, un disco duro USB y conecté un cable HDMI para ver cómo afectaría cada accesorio/función al consumo de energía. Los números muestran los mA adicionales aproximados por elemento en comparación con inactivo.

WiFi es mucho más eficiente que Ethernet, especialmente cuando está inactivo, los discos duros consumen mucha energía cuando se conectan inicialmente y la conexión de un cable HDMI solo afecta marginalmente el consumo de energía.

El gráfico de iperf Ethernet muestra que tanto el voltaje como la corriente eran estables al principio, y de alguna manera fluctúan un poco más después de unos 20 segundos, ¿tal vez se produzcan colisiones de paquetes después de un tiempo? También hay un pico corto a 516 mA, pero podría estar relacionado con otro proceso.

El WiFi es mucho más «ruidoso» y la corriente oscila rápidamente entre 160 y 480 mA durante la transferencia de datos. La energía total es ligeramente más baja que la de Ethernet, pero se transfirieron menos datos.

Conectar un disco duro USB lo convierte en un gráfico bonito con un alto consumo de corriente al principio hasta 1.06A, seguido de picos mientras se montan las particiones. Después de un tiempo, el sistema se estabiliza a 386 mA en promedio.

iozone no se puede instalar con apt en Raspberry Pi OS, así que construí iozone 3.492 con las mismas instrucciones que en mi revisión de Raspberry Pi 4.

También es difícil mirar en los detalles de la forma en que está escrita la consola, pero parece que las escrituras consumen más que las lecturas.

Para comprobar la potencia y el consumo de energía bajo carga, utilicé el script SBC Bench de Thomas Kaiser lanzado desde la consola serie Otii.

Podemos ver claramente la prueba de compresión/descompresión de 7 zip multiproceso a la derecha con un consumo de energía mucho mayor con picos cercanos a 600 mA.

Si seleccionamos el texto entre «tinybench» y «cpufreq OPP» en la consola serial, podemos ver que el benchmark real (excluyendo la instalación y la post-ejecución) usó 328 mWh de energía, con un pico de 624 mA, y un tiempo de ejecución de 14 minutos y 17 segundos. Tengamos esos números en mente, ya que los usaremos más adelante.

Todavía estamos lejos de nuestro objetivo de 2.5A con un pico de 1.06 A hasta ahora. Así que probemos Raspberry Pi OS Desktop en su lugar.

El promedio es 124 mA, que es aproximadamente el mismo que en la imagen Lite, pero hay muchos picos de alrededor de 300 mA.

Si conecto un monitor HDMI, el promedio sube a solo 131 mA. La idea era conectar USB Ethernet, hardware USB, teclado y mouse a través de un concentrador USB para probar el sistema, pero ninguno de mis concentradores USB funcionará con la Raspberry Pi Zero 2 W:

Así que renuncié a esa parte y simplemente conecté la unidad USB al puerto USB OTG y al WiFi.

Planeaba reproducir videos de YouTube y ejecutar algunos puntos de referencia de gráficos 3D como OpenArena, pero con solo 512 MB de RAM eso es pedir demasiado … OpenArena podría iniciarse, y podría seleccionar «Demo», pero se bloqueó sin fallar mientras cargaba la demostración. Así que ejecuté es2gears en su lugar (que realmente parece ejecutar un renderizador de software), inserté el disco duro, ejecuté iozone y luego estresé-ng. Eso significa que es2gears, iozone y stress-ng estaban funcionando al mismo tiempo.

Esto alcanzó un máximo de 1,35 A, con suficiente espacio para la cabeza usando los 5V/2,5 A recomendados fuente de alimentación. Aunque lo tuve más largo que la captura de pantalla anterior y tuve al menos un pico en 1.46A. Si hubiera ejecutado stress-ng primero y luego hubiera insertado la unidad USB, probablemente tendríamos un pico ligeramente más alto, que calcularía en 1.7 o 1.8A. Estoy seguro de que podría haberme acercado a 2.5A si hubiera podido reproducir un video desde el disco duro, ejecutar una demostración de gráficos en 3D, mientras se ejecuta stress-ng. Pero sin un concentrador USB que funcione, ni un teclado Bluetooth, eso es un desafío. De todos modos, eso significa que en la mayoría de los casos, una fuente de alimentación más débil, incluso 5V/1A sería suficiente con Raspberry Pi Zero 2 W. No he podido probar una cámara MIPI CSI porque no tengo ninguna.

Reducción del consumo de energía de Raspberry Pi Zero 2 W

Volvamos a la imagen de Raspberry Pi OS Lite con solo UART y SSH habilitados y nada más a 125 mA inactivo. Haremos algunas modificaciones para intentar reducir el consumo de energía principalmente a través de la utilidad raspi-config y editando config.txt.

Obliguemos a Raspberry Pi RP3A0 a 600 MHz.

No espero mejoras aquí mientras está inactivo … y de hecho tenemos 127 mA de alguna manera. Desactivemos la GPU por completo configurando la memoria en 16:

Todavía 127 mA de media en reposo …

Podemos deshabilitar el LED en teoría agregando las siguientes líneas en config.txt:

Pero no me funciona si configuro la segunda línea en apagado o encendido. Pero puedo apagar el LED manualmente desde la línea de comando:

Afeita de 1 mA a 126 mA, o aproximadamente 5 mW. Lo que es muy extraño es que a veces tengo que ejecutar lo siguiente para apagar el LED:

Ahora deshabilitemos el audio, WiFi y Bluetooth, y la cámara / pantalla detecta automáticamente en config.txt:

Hemos bajado a 114 mA, en lugar de 125 mA cuando ejecutamos la imagen por primera vez sin modificaciones, es decir, la configuración predeterminada no incluye WiFi, pero SSH y UART habilitados. Eso es un pequeño ahorro de 9 mA.

Otro truco es deshabilitar HDMI con el siguiente comando:

Pero aparentemente no funciona debido al nuevo controlador de video KMS estándar para gráficos 3D en Raspberry Pi OS Bullseye:

Podemos ir a raspi-config para cambiar eso, es decir, en «Advanced options->GL driverG1 Legacy«.

Cambiará config.txt de:

a

¡Ahora estamos hablando! El consumo bajó a 92,7 mA, o alrededor de 21 mA menos, y todavía tenemos que desactivar la salida HDMI:

Eso es hasta 75,5 mA, otros ~17 mA. Si desea deshabilitar HDMI automáticamente en el momento del arranque, agregue la línea al archivo /etc/rc.local. Ahí es también donde terminé apagando el LED (simplemente no me preguntes por qué no necesito ejecutar la línea para configurarla en 0 o 1):

Tenemos un truco más que probablemente no reducirá mucho el consumo de energía inactivo, pero Jeff Geerlink proporcionó instrucciones para deshabilitar los núcleos, así que modifiquemos /boot/cmdline.txt para limitar el número de núcleos a uno con maxcpus=1:

Funciona ya que solo podemos ver un núcleo en /proc/cpuinfo:

Pero, ¿qué pasa con el consumo de energía? 74,6 mA, por lo que puede haber algún beneficio limitado en un solo núcleo con respecto al consumo de energía inactivo. Ahora deshabilitemos SSH:

así como UART para ver si podemos llegar a 70 mA.

Lamentablemente no ayudó mucho, ya que pude sólo alcanza 74,5 mA en reposo. Puede haber algunas otras optimizaciones, ya que podemos ver picos de 100 mA de vez en cuando. Algunos procesadores tienen algunos modos de bajo consumo en los que todos los núcleos de la aplicación y algunos bloques se pueden apagar y encender según sea necesario o / y varios modos de suspensión, pero no pude encontrar nada para el procesador Broadcom BCM2837/BCM2710A.

Uso de energía

Ahora veamos si es posible reducir el uso de energía ajustando la frecuencia y la cantidad de núcleos utilizados. Eso es útil para el funcionamiento con batería. Volveré a ejecutar el banco SBC con cuatro núcleos a la frecuencia predeterminada (1.0 GHz) con WiFi, SSH y algunas de las optimizaciones que hemos habilitado para verificar cómo afecta el uso de energía. Como referencia, el consumo de energía inactivo es un poco menos de 80 mA en esta configuración.

Los resultados completos se pueden encontrar en http://ix.io/3HrM. Eso es extraño, porque se utilizó un poco más de energía con 338 mWh que en nuestra primera ejecución sin optimización (328 mWh), y la prueba tardó 16 minutos y 49 segundos en completarse (frente a 14:17), mientras que el consumo máximo de corriente fue de 635 mA. Pensé que no había guardado los primeros resultados, pero afortunadamente, guardé las medidas de potencia y Otii mantendrá la salida en serie, por lo que pude recuperar los primeros resultados @ http://ix.io/3H54.

Una revisión rápida en 7-Zip para comparar la primera ejecución:

con el segundo:

revela algunas diferencias mínimas de rendimiento.

Comparé ambas salidas en Meld y no pude ver mucha diferencia, aparte de que el controlador KMS está habilitado y el porcentaje de inactividad más alto en la primera ejecución, porcentajes de espera ligeramente más altos en la segunda.

De todos modos, cambiemos al uso de cuatro núcleos a 600 Mhz para ver si podemos ahorrar energía y extender la vida útil de la batería mientras ejecutamos las mismas tareas.

Salida completa: http://ix.io/3HrU. Curiosamente, se usó casi la misma cantidad de energía con 331 mWh (aún 7 mWh menos, pero similar a la primera ejecución a 1.0 GHz), y la prueba tomó el tiempo esperado en 23 minutos y 18 segundos. El consumo máximo de energía fue de solo 449 mA, lo que significa que la placa se puede alimentar de forma segura mediante un puerto USB desde un enrutador o computadora con esta carga de trabajo.

Hagamos una ejecución final con una configuración de un solo núcleo a 600 MHz.

Resultados completos: http://ix.io/3Hsg. El consumo de energía es mucho mayor a 483 mWh, tal vez se deba a la forma en que 7-zip maneja la compresión / descompresión «multinúcleo» en un sistema de un solo núcleo, no lo sé, tal vez alguien tenga una idea en la sección de comentarios . Como era de esperar, también tomó mucho más tiempo completar todo: 43 minutos y 50 segundos. La única ventaja potencial es que el consumo máximo de corriente fue de solo 349 mA, pero nuevamente esto es exactamente como debería ser ya que se apagaron tres núcleos.

[Actualización: después de la discusión en el comentario (en el sitio web en inglés), me di cuenta de que debería haber tomado medidas durante la misma cantidad de tiempo debido al consumo de corriente inactivo, así que ajustaré los resultados a 43m50s usando 80 mA de energía inactiva consumo para los dos primeros escenarios para tener una mejor idea de las diferencias:

• 4 núcleos a 1000 MHz: 338 mWh (16:49) + 180 mWh (27:01) = 518 mWh
• 4 núcleos a 600 MHz: 331 mWh (23:18) + 137 mWh (20:32) = 468 mWh
• 1x núcleo a 600 MHz: 483 mWh

Eso significa que aquí simulamos una carga de trabajo en la que sbc-bench se ejecuta en la placa cada ~44 minutos, excluyendo la instalación y la actividad posterior a la evaluación comparativa. El resultado real obviamente dependerá de su aplicación/carga de trabajo específica.
]

Eso será todo por ahora. No dude en preguntarme si necesita que pruebe algo más mientras todavía tengo el banco de pruebas en mi escritorio.

Traducido del artículo en inglés «A deep dive into Raspberry Pi Zero 2 W’s power consumption«.

CNXSoft

Publicaciones traducidas automáticamente