Авторът на този материал предпочита да използва никнейма nachoparker и

...
Авторът на този материал предпочита да използва никнейма nachoparker и
Коментари Харесай

Какво не е наред с Raspberry Pi

Авторът на този материал избира да употребява прякора nachoparker и е доста известен в Глобалната мрежа. Тук той споделя своя опит за работата с едноплатковия миникомпютър Raspberry Pi, както и някои забавни размишления и хрумвания.
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`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
Източник: kaldata.com

СПОДЕЛИ СТАТИЯТА



Промоции

КОМЕНТАРИ
НАПИШИ КОМЕНТАР