Пришло время ответов на часто задаваемые вопросы, и один из топовых в данном случае касается overclocking'а, то есть разгона Raspberry Pi. Операции и манипуляции я буду проводить на Raspberry Pi 4 Model B 8GB, но основные аспекты и идеи справедливы и для других модификаций. Переходим непосредственно к сути вопроса...
Но сначала небольшое, но обязательное предупреждение. Заключается оно в том, что любые действия подобного рода, переводящие то или иное оборудование в режимы, официально не предусмотренные, могут повлечь за собой ряд побочных эффектов ) Среди которых - потеря гарантии на плату, банальный выход из строя (в основном это происходит при отсутствии должного охлаждения) и тому подобные нежелательные события. Так что действовать нужно обдуманно и в меру осторожно. На этом с обязательной частью покончено, двигаемся дальше.
Подготовка.
Итак, зачем вообще разгонять Raspberry Pi? Ответ банален - есть задача, производительности для ее решения не хватает - вот и вся причина. Почему плата изначально, с завода, не работает на пределе своих возможностей? Не в последнюю очередь из-за того, что конструктивно не предусмотрено должного охлаждения. Собственно, поэтому первый шаг - озадачиться либо подготовкой внешнего кулера, либо установкой дополнительных радиаторов. Здесь все индивидуально, в идеале необходимо по крайней мере какое-то время мониторить температурное состояние процессора и других элементов, чтобы иметь в целом представление о происходящем.
Помимо повышенной вероятности выхода платы из строя отсутствие должного охлаждения имеет и еще один негативный эффект. Процессор при перегреве банально уйдет в троттлинг, что предполагает по сути искусственное занижение производительности во избежания перегрева. И по итогу, разогнанный, но перегретый процессор, будет иметь меньшую производительность, чем изначальный вариант, до разгона. Такие вот дела.
Я сейчас использую банальнейший кулер с Озона, использовался он изначально для другого проекта, но по мере необходимости нашел свое место по соседству с Raspberry Pi:
Но у меня сейчас идет активная отладочная деятельность, поэтому все это находится на столе, соответственно найти 12 Вольт для питания кулера - не проблема. Я просто зацепил его на стоящий тут же рядом источник питания:
В полевых условиях для конечных изделий это скорее всего окажется не слишком удобно, здесь все индивидуально и зависит от конкретных задач и требований. Неизменным остается одно - охлаждение необходимо (!)
Сердцем Raspberry Pi 4 является процессор BCM2711 от Broadcom, который может спокойно работать на частотах выше, чем дефолтные 1.5 GHz. Так что дело за малым - осуществить желаемое 👍
Overclocking.
Резюмируем вводные данные, опять же, это мой текущий набор элементов, суть процессов будет похожей и для других вариантов:
- плата Raspberry Pi 4 Model B
- охлаждение, описано выше
- операционная система - Raspberry Pi OS (64-bit)
- Release date: May 3rd 2023
- System: 64-bit
- Kernel version: 6.1
- Debian version: 11 (bullseye)
- питание - Official Raspberry Pi 4 Power Supply, 5.1В, 3A
- монитор у меня подключен по hdmi
- клавиатура/мышь
Я перешел на официальное питание, поскольку Raspberry Pi 4 является даже еще более нежной, чем предыдущие версии, чуть что, так начинаются проблемы. На этом вроде бы все... И для начала разберем непосредственно механизмы разгона, а затем произведем ряд измерений и тестов для наглядной оценки.
Шаг 1. Актуализируем ПО.
Начинаем с того, что обновимся, если это не сделано ранее:
sudo apt update -y sudo apt upgrade -y
В случае желания или необходимости:
sudo apt dist-upgrade
sudo apt install rpi-update
В завершение перезапустимся:
sudo reboot
Шаг 2. Редактируем /boot/config.txt.
Переходим к редактированию файла /boot/config.txt. Я обычно пользуюсь редактором gedit, само собой использовать можно и любой другой. Физически задача проста - внести изменения в упомянутый файл. Открываем:
sudo gedit /boot/config.txt
В этом файле нужно найти закомментированную строку #arm_freq=800, раскомментировать ее и редактировать непосредственно здесь же. А редактирование будет включать в себя следующее:
- arm_freq - собственно, здесь мы устанавливаем максимально допустимую частоту для процессора
- аналогично, для GPU нужно добавить и в дальнейшем редактировать gpu_freq. Измерение этого параметра автоматически влечет за собой изменение: core_freq, h264_freq, isp_freq, and v3d_freq. То есть задавать их отдельно в данном случае необходимости нет
- а также необходимо отрегулировать напряжение CPU/GPU посредством редактирования величины over_voltage.
Резюмируем, нам нужно добавить в файл строки следующего вида:
over_voltage=6 arm_freq=2147 gpu_freq=750
Здесь я установил передельные относительно безопасные значения для Raspberry Pi 4 Model B, которых в большинстве случаев бывает достаточно для ощутимого эффекта от разгона. А, если в целом говорить о значениях, то:
- arm_freq - значение частоты в МГц
- gpu_freq - здесь также значение частоты в МГц
- over_voltage - допустимы значения от -16 до 8. Этим значениям параметра соответствуют напряжения от 0.8 до 1.4 В с шагом 0.025В, проще говоря:
- -16: 0.8 В
- -15: 0.8 В + 0.025 В = 0.825 В
- ...
- 0: 1.2 В
- ...
- 8: 1.4 В
Сохраняем файл, перезапускаем плату и получаем разогнанный вариант, к чему мы и стремились. Но на этом еще далеко не все.
Шаг 3. Форсируем.
По умолчанию плата не будет всегда работать на максимальных частотах, которые мы задали. Частоты будут меняться динамически в зависимости от текущей нагрузки. А чтобы изменить это поведение, то есть буквально заставить Raspberry Pi крутиться на максималках всегда, существует еще одна опция, также помещаемая в /boot/config.txt:
force_turbo=1
И итоговый вариант:
over_voltage=6 arm_freq=2147 gpu_freq=750 force_turbo=1
В файле /boot/config.txt это выглядит так:
Теперь динамическое регулирование частот отключено и плата будет работать на указанных значениях даже при малой нагрузке. Перезапускаемся, и дело сделано. Но, конечно же, мы не завершим эту тему, не протестировав все и досконально не проанализировав. Так что продвигаемся к практической части.
Тестируем.
Обзаведемся исходной температурной точкой, то есть произведем замер температуры для базового состояния платы и ОС, то есть до разгона и без внешнего активного охлаждения. Единственное что, у меня на плате установлены радиаторы.
Тест 0. Подготовка.
Собственно, что мы хотим? А хотим мы мониторить в реальном времени, во-первых, температуру, а во-вторых частоту процессора. Этим целям послужат команды:
watch -n1 vcgencmd measure_temp watch -n1 vcgencmd measure_clock arm
Запускаем в разных окнах и наблюдаем, далее без лишних слов приведу полученные значения.
Тест 1. Плата до разгона, без внешнего охлаждения.
Тест 2. Плата до разгона, с внешним охлаждением.
Все эти значения могут варьироваться в зависимости от внешних условий, главное динамика.
Тест 3. Плата после разгона, с внешним охлаждением.
Как видите, частота повышена в соответствии с нашей конфигурацией в /boot/config.txt.
Тест 4. Производительность до разгона.
Для теста производительности используем sysbench, устанавливаем в случае отсутствия:
sudo apt install sysbench
Далее запускаем:
sysbench --num-threads=8 --test=cpu --cpu-max-prime=20000 run
И получаем результат:
Тест 5. Производительность после разгона.
А теперь аналогичные действия но на overclock-версии:
Собственно, можем наглядно наблюдать, что результат действительно соответствует ожиданиям. Для возврата Raspberry Pi в исходное состояние просто спокойно убираем добавленные в /boot/config.txt строки и перезапускаем плату, на этом все готово.
Что делать, если плата не запускается в результате манипуляций с /boot/config.txt? Решение таково:
- извлекаем карту памяти из платы
- вставляем эту карту в "обычный" ПК
- заходим в "boot" и находим файл config.txt
- редактируем файл, то есть возвращаем к тому состоянию, при котором с запуском платы проблем не было
- сохраняем файл, извлекаем карту, возвращаем ее в Raspberry Pi
- успешно запускаемся
Ну и продублирую предупреждение, так уж принято. Любые действия подобного характера (то есть переводящие оборудование в непредусмотренные изначальной конструкцией режимы) осуществляются на свой страх и риск по причинам, указанным в тексте статьи, поэтому MicroTechnics в лице меня не несет ответственности за возможные последствия, уж не обессудьте 🙂
