Raspberry Pi — невероятно популярное устройство, известное своей доступностью, универсальностью, возможностями и активным сообществом. Легко найти фанатские сайты и статьи, но большинство людей не знают о его слабых местах, пока сами не пострадают от них и не поищут информацию на форумах.

Постараюсь рассказать о некоторых вопросах, с которыми я столкнулся лично, а также о некоторых типичных проблемах, которые чаще всего появятся у людей, ничего не подозревающих об этом. И, наконец, почему я не рекомендую Pi для некоторых приложений, в частности, NAS-услуг, таких как NextCloudPi и Open Media Vault. Надеюсь, это сэкономит мне время, чтобы не повторять всё это на форумах.

У меня было много Raspberry Pi, и я использую их в течение многих лет. Когда в 2012 году появилась первая модель, это стало важной вехой на рынке одноплатников. Хотя уже существовало несколько хороших плат, таких как Beagleboard и Odroid, они были довольно дорогими, и только хардкорные любители могли их купить и проверить в деле.

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

Но сейчас 2019 год и пора осмотреться ещё раз. На мой взгляд, есть более открытые альтернативы лучшего качества по той же цене. Постараюсь объяснить.

Производительность

Raspberry Pi снизила цену, срезав углы. В результате плата недостаточно производительна для некоторых задач, по сравнению с конкурентами. В частности, она плохо подходит для сетевых задач и по USB-функциональности.

Здесь стоит микросхема SMSC LAN9514, которая соединяется с SoC одним USB-каналом, действуя в качестве USB-to-Ethernet адаптера и USB-хаба одновременно. Таким образом, Ethernet и USB сидят на одном канале и конкурируют друг с другом, что противоречит типичному использованию NAS, когда что-то загружается по сети и сохраняется на USB-накопитель, не говоря уже о добавлении сюда RAID.

По этой же причине, даже когда в прошлом году они, наконец, выпустили модель с поддержкой Gigabit Ethernet, реальная сетевая производительность никогда даже близко не приближалась к гигабитной, а составляет максимум 40 МБ/с по чистой скорости и максимум 20 МБ/с, если идёт передача на USB-устройство. В то время уже были дешёвые платы с настоящим Gigabit Ethernet и USB3.

На самом деле Wi-Fi не идёт через SMSC, а подключается к чипу BCM4343 через SDIO, так что этого узкого места можно как-то избежать с помощью Wi-Fi. Впрочем, микросхема Wi-Fi не всесильна, ей придётся бороться с окружающими помехами, так что это не идеальная альтернатива.

По указанным причинам я бы не рекомендовал использовать Pi как NAS, будь то Open Media Vault или Nextcloud.

Реальный мозг Pi — с закрытыми исходниками

Если вы участвовали в спорах о свободе ПО, то главная проблема в наших системах Linux — двоичные блобы с закрытым исходным кодом. Не буду вдаваться в подробности, но проблема в том, что эти части системы невозможно проверить, а они имеют доступ ко всему, что происходит в устройстве. Это породило большие open source проекты, такие как Android Replicant, призванные освободить наши системы от любых двоичных блобов: болезненный, утомительный и медленный процесс.

Аналогичная проблема у Raspberry Pi, где CPU и GPU встроены в тот же чип BCM2837B0. Центральный процессор представляет собой 64-разрядный четырёхъядерный ARM A53 на 1400 МГц (в Pi 3B), а графический — двухъядерный 32-разрядный VideoCore IV с частотой 400 МГц. Интеграция CPU и GPU популярна в мобильном мире, потому что снижает цену и энергопотребление. Конкуренты NXP iMX и Allwinner используют аналогичный подход.

Таким образом, в последнем Pi шесть ядер, но только четыре из них ARM. На процессоре работает Linux, но вас может удивить, что Linux на данном устройстве — гражданин второго класса. Ядра GPU работают под управлением операционной системы реального времени ThreadX. Эта ОС с закрытыми исходниками управляет системой без ведома ядра Linux.

В начале загрузки Raspberry Pi процессор полностью отключен (технически в состоянии reset) и именно GPU запускает систему. Можете взглянуть на папку /boot — и найдёте бинарные блобы, с помощью которых GPU запускает процессор и собственную ThreadX OS (bootcode.bin и start.elf). Подробнее о процессе загрузки см. здесь.

Именно GPU монтирует SD-карту, загружает эти блобы и читает конфигурацию из текстового файла config.txt, который мы редактируем, чтобы настроить параметры видео или разогнать GPU. Linux тут не участвует.

Когда GPU позволит CPU загрузить ядро Linux, он не просто уходит со сцены, работая лишь как графический процессор. Нет, GPU по-прежнему главный. Вы когда-нибудь думали, кто выводит эти логотипы, когда Pi подключается к HDMI? Или эти символы молнии или температуры в предупреждающих значках? Вот именно, это делает система ThreadX на GPU, а Linux вообще не знает, что происходит.

Мы не можем знать всей функциональности GPU, но знаем кое-что, за что он отвечает. Для данной статьи важно то, что ThreadX отслеживает снижение напряжение — широко распространённая проблема, как мы увидим дальше, и снижает частоту процессора, чтобы предотвратить сбой процессора и зависание. Поэтому у людей устройства работают на частоте 600 МГц вместо 1400 МГц, в лучшем случае. Такое дросселирование начинается на 4,65 В и его также может инициировать температура. В то же время Linux по-прежнему думает, что система нормально работает на полной частоте.

Это только то, что мы видим. Поскольку основная ОС проприетарна, у нас нет способа узнать, что ещё она делает или способна делать, поэтому всегда остаётся проблема с приватностью.

Существует по крайней мере один патент, включенный в блоб с закрытым исходным кодом, который запрещает открытие кода по крайней мере до 2025 года, но мы не знаем, будет ли это сделано даже тогда. Были попытки реверс-инжиниринга VideoCore IV и создания open source прошивки для него. К сожалению, проект умер прежде, чем выдал что-то полезное. Как и с блобами Android, это невероятно трудная работа.

Проблемы питания

Это не техническая ошибка Raspberry Pi, а скорее типичная ошибка пользователя.

Первая модель едва использовала 80 мА, но каждое новое поколение становилось всё более мощным, и по этой причине более энергозатратным. Кроме того, многие пользователи подключают USB-устройства, которые также потребляют энергию, если не поставляются с собственными источниками питания.

Разъём microUSB первоначально был рассчитан только на 1,8 A, и хотя это старый стандарт, и вы можете найти зарядные устройства, которые выдают больше, поэтому многие люди пытаются использовать старые зарядные устройства телефона на 1 A или купить в интернете дешёвые адаптеры для питания своих «малинок». Но Pi — это компьютер, и он требует качественного, стабилизированного электропитания, которое обеспечивает стабильные 5 В на входе с силой тока до 2,5 A. Нужен не только пристойный трансформатор, но и качественное соединение (или произойдёт падение напряжения), но более важно, что нужен хороший кабель, иначе сильно упадёт напряжение по нему. Плохие кабели встречаются ещё чаще, чем нестабильные источники напряжения, поэтому обязательно используйте хороший кабель: возможно, 20AWG или аналогичный, или просто купите официальный источник питания. Вывод в том, что не любое зарядное устройство USB будет работать должным образом, даже если это 2.5A 5V.

Добавьте это к тому, что мы обсуждали в прошлом разделе, и начнёте понимать общую картину. Большинство пользователей работают на своих устройствах с пониженной частотой, и GPU скрывает это от них, поэтому они фактически работают с пониженной частотой 600 МГц: почти так же, как ARMv6 на самом первом Pi.

Во многих случаях усилий GPU недостаточно, и система случайным образом выходит из строя или просто зависает, возможно, повреждая данные или повреждая SD-карту. Это обычно случается под нагрузкой, то есть когда транзисторам требуется максимальное питание. Затем пользователь приходит на форумы и жалуется: мой блок питания в порядке, я запускал это и то, и ничего не сбойнуло. Конечно, это неправда, но часто они в это не верят.

На мой взгляд, здесь то, что японцы могут назвать Poka Yoke, то есть мы должны проектировать такие системы, которые по своему дизайну не дадут пользователю выстрелить себе в ногу. Опять же, официальный источник питания очень хорошего качества для своей цены, и я очень его рекомендую.

Мне не нравится, что скрытая проприетарная система понижает частоту вне нашего контроля. Лучше бы система зависала: тогда сразу видно, что происходит, и человек может заменить блок питания. По-моему, это лучше, чем обманывать пользователей и заставлять их жаловаться по всему интернету. Трудно представить себе причину, по которой разработчики Pi сделали бы это, если бы не скрывали проблему Poka Yoke.

Проверка проблем с питанием

Это заняло слишком много времени, но мы всё-таки сумели залоггировать проблему на уровне ядра. Если видите такое сообщение в системных логах:

kern  :crit  : [ 1701.464833    2.116656] Under-voltage detected! (0x00050005)
kern  :info  : [ 1707.668180    6.203347] Voltage normalised (0x00000000

то у вас происходит понижение напряжения. Хорошо, что сейчас Linux фиксирует хотя бы такую информацию, но если мы хотим узнать больше, нужен прямой доступ к GPU.

Команда vcgencmd может получить от прошивки ThreadX информацию о системе.

# vcgencmd get_config int
arm_freq=1000
core_freq=500
sdram_freq=600
over_voltage=6
disable_overscan=1
force_pwm_open=1

Можно использовать команды vcgencmd measure_clock arm и vcgencmd measure_volts для проверки реальной частоты и напряжения. Вот пример выходных данных скрипта мониторинга от tkaiser.

# With a crappy PSU and/or Micro USB cable output looks like this
# on a RPi 3:
#
# 44.0'C  600 MHz 1010000000000000000 1.2V
# 44.5'C  600 MHz 1010000000000000000 1.2V
# 44.0'C  600 MHz 1010000000000000101 1.2V
# 44.0'C  600 MHz 1010000000000000101 1.2V
# 44.0'C  600 MHz 1010000000000000101 1.2V
# 44.5'C  600 MHz 1010000000000000000 1.2V
# 45.1'C  600 MHz 1010000000000000101 1.2V
# 
# With an ok-ish cable it looks like this (when running cpuburn-a53):
# 
# 48.3'C 1200 MHz 0000000000000000000 1.3312V
# 48.3'C 1200 MHz 0000000000000000000 1.3312V
# 48.3'C 1200 MHz 0000000000000000000 1.3312V
# 48.3'C 1200 MHz 0000000000000000000 1.3312V
# 50.5'C 1200 MHz 0000000000000000000 1.3312V
# 56.4'C  600 MHz 0000000000000000000 1.2V
# 54.8'C  600 MHz 1010000000000000101 1.2V
# 55.3'C  600 MHz 1010000000000000101 1.2V
# 55.8'C  600 MHz 1010000000000000101 1.3312V
# 53.7'C  600 MHz 1010000000000000101 1.2V
# 51.5'C  600 MHz 1010000000000000101 1.2V
# 51.0'C  600 MHz 1010000000000000101 1.2V
# 
# And only by bypassing the crappy connector you can enjoy RPi 3
# performing as it should (please note, there's a heatsink on my RPi
# -- without throttling would start and then reported clockspeed
# numbers start to get funny):
# 
# 75.2'C 1200 MHz 1010000000000000000 1.3250V
# 75.8'C 1200 MHz 1010000000000000000 1.3250V
# 75.8'C 1200 MHz 1010000000000000000 1.3250V
# 76.3'C 1200 MHz 1010000000000000000 1.3250V
# 76.3'C 1200 MHz 1010000000000000000 1.3250V
# 73.6'C 1200 MHz 1010000000000000000 1.3250V
# 72.0'C 1200 MHz 1010000000000000000 1.3250V
# 70.4'C 1200 MHz 1010000000000000000 1.3250V
#
# Now with a pillow on top for some throttling:
#
# 82.2'C 1200/ 947 MHz 1110000000000000010 1.3250V
# 82.7'C 1200/ 933 MHz 1110000000000000010 1.3250V
# 82.7'C 1200/ 931 MHz 1110000000000000010 1.3250V
# 82.7'C 1200/ 918 MHz 1110000000000000010 1.3250V
# 82.2'C 1200/ 935 MHz 1110000000000000010 1.3250V
# 79.9'C 1200/1163 MHz 1110000000000000000 1.3250V
# 75.8'C 1200 MHz 1110000000000000000 1.3250V
#
# And here on RPi 2 with crappy USB cable and some load
#
# 50.8'C  900 MHz 1010000000000000000 1.3125V
# 49.8'C  900 MHz 1010000000000000000 1.3125V
# 49.8'C  900/ 600 MHz 1010000000000000101 1.2V
# 49.8'C  900/ 600 MHz 1010000000000000101 1.2V
# 48.7'C  900/ 600 MHz 1010000000000000101 1.2V
# 49.2'C  900/ 600 MHz 1010000000000000101 1.2V
# 48.7'C  900 MHz 1010000000000000000 1.3125V
# 46.5'C  900 MHz 1010000000000000000 1.3125V
#
# The funny thing is that while the kernel thinks it's running
# with 900 MHz (performance governor) in reality the 'firmware'
# throttles down to 600 MHz but no one knows :)

Вывод

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

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