Подробное описание энергопотребления Raspberry Pi Zero 2 W

Когда мы завершили наш обзор Raspberry Pi Zero 2 W, мы упомянули, что позже протестируем энергопотребление платы. Нам потребовалось определенное время, и, наконец, мы сделали это, используя Otii Arc от Qoitech и программное обеспечение Otii, чтобы продемонстрировать вам красивые диаграммы энергопотребления. Поскольку Raspberry Pi Foundation рекомендует источник питания 5 В/2,5 А, мы сначала постараемся получить значение как можно ближе к 2,5 А, а затем попробуем снизить энергопотребление в режиме ожидания до менее 75 мА/375 мВт, и, наконец, проверим энергопотребление при различном количестве ядер ЦП и частоте.

Энергопотребление Raspberry Pi Zero 2 W под нагрузкой, с аксессуарами

Начнем с последнего образа Raspberry Pi OS Lite «Bullseye» и подключим нашу плату Raspberry Pi Zero 2 W к инструментам Qoitech Otii Arc, как показано ниже. Раньше он стоил около 500 долларов, но теперь цены начинаются с 699 долларов, и это отличный инструмент для людей, разрабатывающих устройства с батарейным питанием.

Давайте включим Raspberry Pi и проверим энергопотребление в режиме ожидания, используя образ, который мы только что прошили без каких-либо изменений.

Это примерно 120 мА при 5 В или 600 мВт. Если вы видели более низкие цифры в более ранних обзорах Raspberry Pi Zero 2 W, это потому, что мы используем образ Bullseye для Raspberry Pi OS вместо образа Buster, и позже мы объясним причину, почему это так.

Энергопотребление в режиме ожидания – Raspberry Pi Zero 2 Вт (зеленый) против Raspberry Pi Zero (красный)

У нас также есть Raspberry Pi Zero (без Wi-Fi), и он потребляет 108 мА с тем же образом.

Еще одна интересная функция Otii Arc – синхронизация данных измерения мощности с последовательной консолью, поэтому мы подключили провода для доступа к последовательной консоли в программе Otii.

Мы также включили UART в config.txt:

и SSH, создав пустой файл /boot/ssh на карте microSD. Последовательная консоль в Otii не очень удобна в использовании, в ней нет истории, можно запускать такие программы, как vim или raspbi-config и т. д. Мы будем много работать над SSH, так как не нужно сопоставлять последовательный консольный выход с данными V/A. После этого потребляемая мощность выросла до 125 мА.

Мы протестировали USB-Ethernet, Wi-Fi, жесткий диск USB и подключение кабеля HDMI, чтобы увидеть, как каждый аксессуар/функция повлияют на энергопотребление. Цифры показывают приблизительный дополнительный ток в мА на каждый элемент по сравнению с режимом ожидания.

  Дельта Замечание
USB-адаптер Ethernet

+104 мА Нет сетевого подключения, только подключенный USB-адаптер Ethernet 
USB-адаптер Ethernet  + link +180 мА После подключения кабеля Ethernet
USB-адаптер Ethernet + iperf +244 мА Среднее значение см. в таблице ниже.
2,4 ГГц Wi-Fi +11 мА Подключен к точке доступа 2,4 ГГц
2,4 ГГц WiFi + iperf +187 мА Среднее значение, подробности см. в таблице ниже.
RF-адаптер Logitech для клавиатуры / мыши  +29 мА  
Жесткий диск Seagate USB (в режиме ожидания) +255 мА Стабильный ток после первоначальной установки, достигший максимума 1,06. См. подробную информацию в таблице ниже.
Жесткий диск Seagate USB (iozone) +554 мА Среднее значение, подробности см. в таблице ниже.
HDMI cable +7 мА Обратите внимание, это только после вставки кабеля, а не о включении/отключении HDMI. Подробнее об этом ниже

Wi-Fi намного эффективнее, чем Ethernet, особенно в режиме ожидания, жесткие диски потребляют много энергии при первоначальном подключении, а подключение кабеля HDMI лишь незначительно влияет на энергопотребление.

Диаграмма iperf Ethernet показывает, что напряжение и ток были стабильными вначале и как-то немного колеблются примерно через 20 секунд, возможно, через некоторое время возникнут конфликты пакетов? Также есть короткий всплеск до 516 мА, но это может быть связано с другим процессом.

Wi-Fi намного более «шумный», поскольку во время передачи данных ток быстро колеблется от 160 до 480 мА. Общая энергия немного ниже, чем у Ethernet, но данных было передано меньше.

Подключение жесткого диска USB дает красивую диаграмму с высоким потребляемым током вначале до 1,06 А, за которым следуют пики при установке раздела (ов). Через некоторое время система стабилизируется в среднем до 386 мА.

iozone не может быть установлен с apt в ОС Raspberry Pi, поэтому мы построили iozone 3.492 с теми же инструкциями, что и в нашем обзоре Raspberry Pi 4.

Трудно разобраться в деталях и в том, как написана консоль, но, похоже, запись потребляет больше, чем чтение.

Для проверки мощности и энергопотребления под нагрузкой мы использовали скрипт SBC Bench Томаса Кайзера, запущенный с последовательной консоли Otii.

Справа мы видим многопоточный тест сжатия/декомпрессии 7-zip с гораздо более высоким энергопотреблением с пиковыми значениями, близкими к 600 мА.

Если мы выберем промежуток между «tinybench» и «cpufreq OPP» в последовательной консоли, мы увидим, что фактический тест (за исключением установки и выполнения) использовал 328 мВтч энергии с пиковым значением 624 мА и временем работы 14 минут 17 секунд. Запомним эти числа, так как мы будем использовать их позже.

Мы все еще далеки от нашей цели 2,5 А с пиковым значением 1,06 А. Так что давайте попробуем Raspberry Pi OS Desktop.

Среднее значение составляет 124 мА, что примерно так же, как на образе Lite, но есть много скачков примерно до 300 мА.

Если мы подключим монитор HDMI, средний ток вырастет до 131 мА. Идея заключалась в том, чтобы подключить USB-Ethernet, USB-оборудование, клавиатуру и мышь через USB-концентратор для стресс-тестирования системы, но ни один из наших USB-концентраторов не будет работать с Raspberry Pi Zero 2 W:

Поэтому мы отказались от этой части и просто подключили USB-накопитель к порту USB OTG и Wi-Fi.

Мы планировали воспроизводить видео на YouTube и запускать некоторые тесты 3D-графики, такие как OpenArena, но имея всего 512 МБ ОЗУ, это слишком … OpenArena может запуститься, и мы могли выбрать «Демо», но при загрузке демоверсии он обязательно вылетает. Вместо этого мы запустили es2gears (который запускает программный рендер), вставили жесткий диск, запустили iozone, а затем stress-ng. Это означает, что es2gears, iozone и stress-ng работали одновременно.

Максимальный ток достигал 1,35 А, при этом по-прежнему оставался достаточный запас мощности при использовании рекомендованного источника питания 5 В/2,5 А. Хотя у нас он был длиннее, чем на скриншоте выше, и у нас был хотя бы один пик на 1.46A. Если бы мы сначала запустили stress-ng, а затем подключили USB-накопитель, у нас, вероятно, был бы немного более высокий пик, который мы бы оценили в 1,7 или 1,8 А. Мы уверены, что могли бы приблизиться к 2,5 А, если бы могли воспроизводить видео с жесткого диска, запускать демонстрацию 3D-графики во время работы stress-ng. Но без рабочего USB-концентратора и Bluetooth-клавиатуры это сложно. В любом случае, это означает, что в большинстве случаев более слабого источника питания, даже 5 В/1 А, будет достаточно для Raspberry Pi Zero 2 W. Мы не смогли протестировать камеру MIPI CSI, так как у нас ее нет.

Снижение энергопотребления Raspberry Pi Zero 2 W

Давайте вернемся к образу Raspberry Pi OS Lite с включенными только UART и SSH и ничем другим при 125 мА на холостом ходу. Мы внесем некоторые изменения, чтобы попытаться снизить энергопотребление, в основном с помощью утилиты raspi-config и редактирования config.txt.

Давайте установим Raspberry Pi RP3A0 на 600 МГц.

Мы не ждем здесь улучшений в idle… и действительно, у нас каким-то образом получилось 127 мА. Давайте полностью отключим графический процессор, установив память на 16:

По-прежнему среднее значение 127 мА на холостом ходу….

Теоретически мы можем отключить светодиод, добавив следующие строки в config.txt:

Это у нас не сработало независимо от того, выключили мы вторую строку или включили. Но мы можем выключить светодиод вручную из командной строки:

Он снижает ток с 1 мА до 126 мА, или примерно на 5 мВт. Что очень странно, иногда нам приходится запускать следующую команду, чтобы выключить светодиод:

Давайте теперь отключим звук, Wi-Fi и Bluetooth, а также автоматическое определение камеры/дисплея в config.txt:

Мы снизились до 114 мА вместо 125 мА, когда мы впервые запустили образ без изменений, то есть настройки по умолчанию, включая отсутствие Wi-Fi, но включенные SSH и UART. Это небольшая экономия в 9 мА.

Еще одна уловка – отключить HDMI с помощью следующей команды:

Но он не работает, по-видимому, из-за нового стандартного видеодрайвера KMS для 3D-графики в Raspberry Pi OS Bullseye:

Мы можем перейти к raspi-config, чтобы изменить это, а именно в «Дополнительные параметры-> Драйвер GL», где он установит некоторые пакеты, а затем мы можем выбрать «G1 Legacy».

Изменяем config.txt с:

на

Потребляемая мощность снизилась до 92,7 мА, или примерно на 21 мА меньше, и нам еще предстоит отключить выход HDMI:

То есть до 75,5 мА, еще ~ 17 мА. Если вы хотите отключить HDMI автоматически во время загрузки, добавьте строку в файл /etc/rc.local. Мы выключили светодиод (только не спрашивайте нас, почему нам не нужно запускать строку, чтобы установить ее на 0 или 1):

У нас есть еще один трюк, который, вероятно, не сильно снизит энергопотребление в режиме ожидания, но Джефф Гирлинк предоставил инструкции по отключению ядер, поэтому давайте изменим /boot/cmdline.txt, чтобы ограничить количество ядер до одного с maxcpus = 1 :

Это работает, поскольку мы можем видеть только одно ядро ​​в /proc/cpuinfo:

А как насчет энергопотребления? 74,6 мА, поэтому одно ядро ​​может получить некоторую ограниченную выгоду в отношении энергопотребления в режиме ожидания. Теперь отключим SSH:

а также UART, чтобы увидеть, сможем ли мы достичь 70 мА.

К сожалению, это не сильно помогло, так как мы смогли достичь только 74,5 мА в холостом режиме. Возможны и другие оптимизации, поскольку время от времени мы можем наблюдать скачки до 100 мА. У некоторых процессоров есть несколько режимов с низким энергопотреблением, в которых все ядра приложений и некоторые блоки могут быть выключены и включены по мере необходимости или/и в различных режимах сна, но мы не смогли найти ничего для процессора Broadcom BCM2837/BCM2710A.

Потребление энергии

Теперь посмотрим, можно ли снизить потребление энергии, отрегулировав частоту и количество используемых ядер. Это полезно при работе от батареи. Мы повторно запустим тест SBC с четырьмя ядрами на частоте по умолчанию (1,0 ГГц) с Wi-Fi, SSH и некоторыми оптимизациями, которые мы включили, чтобы проверить, как это влияет на потребление энергии. Для справки, в этой конфигурации потребляемая мощность в режиме ожидания составляет чуть менее 80 мА.

Полные результаты можно найти на http://ix.io/3HrM. Это странно, потому что при 338 мВтч было использовано немного больше энергии, чем в нашем первом прогоне без оптимизации (328 мВтч), а для завершения теста потребовалось 16 минут и 49 секунд (против 14:17), а максимальное потребление тока составило 635 мА. Мы думали, что не сохранили первые результаты, но, к счастью, мы сохранили измерения мощности, и Otii сохранит последовательный вывод, так что нам удалось восстановить первые результаты @http://ix.io/3H54 .

Быстрая проверка в 7-Zip для сравнения первого запуска:

со вторым:

показывает минимальные различия в производительности.

Первый запуск (слева) в сравнении со вторым запуском (справа)

Мы сравнили оба выхода в Meld, и мы не увидели большой разницы, кроме включенного драйвера KMS и более высокого процента простоя в первом прогоне, немного более высокого процента iowait во втором.

В любом случае, давайте переключимся на использование четырех ядер с частотой 600 МГц, чтобы посмотреть, сможем ли мы сэкономить энергию и продлить время автономной работы при выполнении тех же задач.

Полный вывод: http://ix.io/3HrU. Интересно, что почти такое же количество энергии было использовано с 331 мВтч (все еще на 7 мВтч меньше, но аналогично первому запуску на частоте 1,0 ГГц), и тест длился, как и ожидалось, 23 минуты 18 секунд. Максимальная потребляемая мощность составила всего 449 мА, что означает, что плата может безопасно питаться от USB-порта маршрутизатора или компьютера с такой нагрузкой.

Давайте сделаем последний запуск с одноядерной конфигурацией при 600 МГц.

Полные результаты: http://ix.io/3Hsg. Энергопотребление намного выше – 483 мВтч, может быть, это из-за способа, которым 7-zip обрабатывает «многоядерное» сжатие/распаковку в одноядерной системе, если у вас есть идеи, делитесь ими в разделе комментариев. Неудивительно, что для завершения всего потребовалось гораздо больше времени: 43 минуты и 50 секунд. Единственное потенциальное преимущество состоит в том, что максимальное потребление тока составляло всего 349 мА, но опять же, это именно то, что должно быть, поскольку три ядра были отключены.

[Обновление: после обсуждения в комментариях мы поняли, что нам следовало проводить измерения в течение того же времени из-за потребляемого тока холостого хода, поэтому мы скорректировали результаты до 43 минут 50 секунд, используя потребляемую мощность 80 мА для первых двух сценариев, чтобы получить лучшее представление о различиях:

  • 4х ядра при 1000 МГц: 338 мВтч (16:49) + 180 мВтч (27:01) = 518 мВтч
  • 4х ядра при 600 МГц: 331 мВтч (23:18) + 137 мВтч (20:32) = 468 мВтч
  • 1x ядро ​​при 600 МГц: 483 мВтч

Это означает, что здесь мы моделируем рабочую нагрузку, при которой sbc-bench запускается на плате каждые ~ 44 минуты, за исключением установки и действий после тестирования. Фактический результат, очевидно, будет зависеть от вашего конкретного приложения/рабочей нагрузки.]

На этом пока все. Не стесняйтесь пишите, если вам нужно чтобы мы протестировали что-то еще, пока у нас на столе все еще есть система отладки.

Выражаем свою благодарность источнику из которого взята и переведена статья, сайту cnx-software.com.

Оригинал статьи вы можете прочитать здесь.

0 0 votes
Article Rating
Подписаться
Уведомление о
guest

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

0 Комментарий
Inline Feedbacks
View all comments