Хабрахабр

[Перевод] Что не так с Raspberry Pi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Большинство пользователей работают на своих устройствах с пониженной частотой, и 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, помогая пользователям установить собственный облачный хостинг.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть