Raspberry Pi е невероятно популярно устройство, известно преди всичко със своята съвсем ниска цена, универсалност, възможности и много активна общност. Лесно се намират сайтовете и статиите на многобройните фенове, но повечето хора не знаят неговите слаби места, докато не се сблъскат с тях и не започнат да търсят информация в технологичните форуми.
Тук ще се спрем на някои моменти, с които се сблъсках лично, както и върху някои типични проблеми, които се проявяват при потребители, които нищо не подозират за това. И накрая, не препоръчвам Raspberry Pi за някои приложения, като например NAS услугите NextCloudPi и Open Media Vault. Надявам се, че този материал ще ви икономиса маса време.
Имах много Raspberry Pi, които използвах в продължение на немалко години. Когато през 2012 година излезе първият модел, това стана важно направление на пазара на едноплатковите компютри. Въпреки че имаше някои нелоши подобни платки, като например Beagleboard и Odroid, те бяха доста скъпи и малко потребители ги купуваха, а още по-малко ги тестваха по-подробно.
Pi не е толкова мощен в сравнение с тях, но поради поразително ниската си цена буквално взриви пазара. Блогове, разширителни платки, огромен брой лични проекти, тонове софтуерни библиотеки… Raspberry Pi създаде всичко това, и именно това е неговото преимущество в сравнение с другите едноплаткови компютри от подобен вид.
Но днес сме 2019 година и е време да се огледаме още веднъж. Според мен, има по-отворени алтернативи с по-добро качество на почти същата цена. Нека обясня.
Производителност
Raspberry Pi намали цената, но с това направи някои опростявания. В крайна сметка платката се оказа недостатъчно производителна в сравнение с конкурентите. Например, тя не е подходяща за мрежови и USB задачи.
Използва се чипа SMSC LAN9514, който е съединен със SoC с помощта на един USB канал, като действа като USB-to-Ethernet и като USB хъб едновременно. По този начин, Ethernet и USB използват един и същ канал и се конкурират, което противоречи на самия принцип за изграждането и използването на NAS. По-конкретно, в случаите, когато нещо се изтегля от мрежата и се съхранява на някое USB устройство – например стик. В този случай и изобщо не може да се говори за RAID масиви.
Това е и причината, че дори и когато миналата година излезе модела с поддръжката на Gigabit Ethernet, реалната мрежова производителност изобщо да не се приближи до гигабитовата, като достига едва 40 MB/s и максимум 20 MB/s, когато мрежовите данни се записват на USB устройство. В същото време се появиха евтини платки от подобен род с истински Gigabit Ethernet и USB3.
Всъщност, безжичната Wi-Fi не преминава чрез SMSC, а се подава към чипа BCM4343 чрез SDIO, така че това тясно място може да се избегне чрез Wi-Fi. Само че Wi-Fi чипът не е всесилен и трябва да се бори с околните шумове, така че това не е пълноценна алтернатива.
Това са причините Raspberry Pi да не се препоръчва за NAS системи, независимо дали като Open Media Vault или Nextcloud.
Истинският мозък на Pi е със затворен код
Ако някога сте участвали в спор за свободата на свободния софтуер, навярно знаете, че към днешен ден главният проблем в Linux са двоичните блокове от данни – блобове, които са със затворен сорс код. Проблемът е че този код не може да бъде проверен, а той има достъп до всичко, което се случва в устройството. Проблемите от подобен род доведоха до създаването на open source проекти, като например Android Replicant, които имат за цел да освободят компютърните системи от каквито и да било блобове. Това е един болезнен, уморителен и бавен процес.
Но същият проблем с пълна сила се проявява в Raspberry Pi, където CPU и GPU са интегрирани в чипа BCM2837B0. Централният процесор включва 4 броя 64-битови ARM A53 ядра с тактова честота 1400 MHz (в Pi 3B), а графичният процесор разполага с двуядрения 32-битов VideoCore IV с честота 400 MHz. Използването на CPU и GPU в един и същи чип масово се използва в мобилния свят, понеже по този начин се намалява цената и консумацията на енергия. Конкурентите NXP iMX и Allwinner правят същото.
Тоест, в последния модел на Raspberry Pi има шест ядра, като само четири от тях са ARM. Процесорът работи под управлението на операционната система Linux, но навярно ще се изненадате, че в този случай Linux е втора цигулка. Оказа се, че графичните ядра работят под управлението на операционната система в реално време ThreadX. Това е ОС със затворен сорс код, която управлява миникомпютъра, без Linux да подозира каквото и да било.
При стартирането, централният процесор на Raspberry Pi е напълно изключен (технически се намира в състояние reset) и именно GPU стартира системата. Можете веднага да погледнете какво има в папката /boot, където ще видите бинарните блобове, с помощта на които графичният процесор стартира собствената ThreadX OS (bootcode.bin и start.elf). Повече подробности за самия процес на зареждането и стартирането могат да се намерят тук.
Именно GPU монтира SD картата памет, зарежда тези блобове и чете конфигурацията от текстовия файл config.txt, който специалистите редактират, за да настроят видеото или да направят лек овърклок на графичния процесор. При тези процеси Linux не взема никакво участие.
Когато GPU позволи на CPU да зареди Linux ядрото, той съвсем не слиза от сцената, за да остане да си работи просто като графичен процесор. Не, GPU както преди, остава главният. Замисляли ли сте се, дали кой извежда тези логотипи, когато Pi се включва към HDMI? Или откъде се вземат тези символи на мълнията и температурата във вид на предупреждаващи иконки? Именно това прави ThreadX, която използва GPU, а Linux изобщо не знае и няма откъде да знае, какво се случва.
Няма как да разберем всичката работа, която върши GPU под управлението на ThreadX OS, но все пак знаем някои неща. За тази статия е важно да подчертаем, че ThreadX извършва мониторинг на напрежението, което е твърде често срещан проблем, и както ще видим по-долу, намалява честотата на процесора, за да се избегне срив или блокиране на системата. Ето защо тези устройства работят с честота около 600 MHz, а не с 1400 MHz, както е по спецификации. Тези промени започват при захранващо напрежение равно и по-ниско от 4,65 V, като могат да бъдат инициирани и от повишаването на температурата. Само че Linux си мисли, че всичко е нормално и SoC работи при максимална честота.
Всъщност само това можем да видим. Понеже основната ОС е със затворен код, няма как да се разбере, какви още неща върши или е способна да върши. Това е сериозен проблем за информационната безопасност и неприкосновеността на личния живот.
Има патент, който се вижда в блоба със затворен код, забраняващ отварянето на кода минимум до 2025 година. Но няма гаранция дали това ще стане. Имаше опити за дизасемблиране на VideoCore IV и създаване на open source фърмуер за него. За съжаление, проектът умря преди да предложи нещо полезно. Както и с блобовете в Android, това е една много трудна работа.
Проблемите със захранването
Това не е някаква технологична грешка в Raspberry Pi, а по-точно типична потребителска грешка.
Първият модел Pi консумираше само 80 mA, но всяко едно следващо поколение ставаше все по-мощно и поради тази причина консумираше повече енергия. Освен това, почти всички потребители включват към Raspberry Pi най-различни USB устройства, които също консумират енергия, ако нямат някакво собствено захранване.
microUSB интерфейсът първоначално трябваше да осигурява само 1,8 А ток. Това е по стария стандарт и поради тази причина потребителите продължават да купуват и да използват стари зарядни за телефон с ток до 1 А или си вземат възможно най-евтините захранвания от интернет магазините. Но Pi си е компютър и иска качествено, стабилизирано захранване със стабилни 5 V при сила на тока до 2,5 А. Необходим е не само достоен трансформатор, но и качествена връзка.
Изключително важно е да се използва качествен кабел, понеже е възможен голям спад на напрежението. Лошите кабели се срещат много по-често, отколкото захранванията без стабилизация. Ако искате устройството да работи както трябва, задължително си вземете добър кабел – например, 20AWG или по-добър. Може би по-доброто решение е да се използва официално захранване, а не някоя евтина имитация. И още веднъж, далеч не всички зарядни за телефони, дори и с 2,5 А ток, са подходящи за захранването на един едноплатков миникомпютър.
Ако добавим това към проблемите, изброени по-горе, започва да се очертава общата картина. Повечето потребители използват Raspberry Pi при осезателно понижена честота, като графичният процесор скрива този факт. На практика се работи с понижена до 600 MHz честота, което е почти същото, като 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'C600 MHz 1010000000000000000 1.2V # 44.5'C600 MHz 1010000000000000000 1.2V # 44.0'C600 MHz 1010000000000000101 1.2V # 44.0'C600 MHz 1010000000000000101 1.2V # 44.0'C600 MHz 1010000000000000101 1.2V # 44.5'C600 MHz 1010000000000000000 1.2V # 45.1'C600 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'C600 MHz 0000000000000000000 1.2V # 54.8'C600 MHz 1010000000000000101 1.2V # 55.3'C600 MHz 1010000000000000101 1.2V # 55.8'C600 MHz 1010000000000000101 1.3312V # 53.7'C600 MHz 1010000000000000101 1.2V # 51.5'C600 MHz 1010000000000000101 1.2V # 51.0'C600 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'C900 MHz 1010000000000000000 1.3125V # 49.8'C900 MHz 1010000000000000000 1.3125V # 49.8'C900/ 600 MHz 1010000000000000101 1.2V # 49.8'C900/ 600 MHz 1010000000000000101 1.2V # 48.7'C900/ 600 MHz 1010000000000000101 1.2V # 49.2'C900/ 600 MHz 1010000000000000101 1.2V # 48.7'C900 MHz 1010000000000000000 1.3125V # 46.5'C900 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 и помагам на потребителите да си инсталират и използват собствен облачен хостинг с негова помощ. Raspberry Pi е изключително популярен и има смисъл да се задълбочаваме в неговото устройство и възможности, софтуер и хардуер, поне докато е полезен на хората.
–What’s wrong with the Raspberry Pi
