Názory k článku Raspberry Pi 4B a Raspbian Buster: první zkušenosti a řešení problémů

Pekny clanek, ale z ceho mam opravdu velkou radost, je ten navod na HPL na konci. Diky moc :)

v jakem rezimu bezi Kodi? u RPi3 bezelo na FB nesystemove (neslo prepnout alt+tab na jinou bezici app, neslo pres \ zmenit fullscreen/window rezim atd...)

Kodi se v Busteru na Rpi4 a Rpi3 chová stejně, alt+tab funguje, \ taky funguje
Jen na Rpi3 jakoby byl zpomalený kurzor myši

U odroidu C2 mam ozkousene, ze kodi v openelec je schopen prehravat lepe nez kodi bezici v ubuntu. hral jsem si s nastavenima synchronizace dlouho ale nic.

je podobny pripad pro raspberry? tedy je kodi v openelec vykonnejsi nez kodi v raspbianu?

diky, nahodil sem na RPi3 Raspbian-Buster a je to jak pises, nejdriv to bylo brutalne pomale, tak sem zapnul v raspi-config (je jen v terminalovem) GL Experimental a Kodi rozhrani je rychlosti skoro normalni, mys trochu zpomalena, ale prehravani (SledovaniTV PVR) je divnej obraz a sekane, nezkousel sem lokalni soubor, ale primar je pro me stejne to PVR :-) mozna u me je problem s horsim zdrojem protoze pri Kodi je neustale videt v rohu blesk :)

Kamos ma Kodi na Rpi3 a jede mu skvele. Ja mel donedavna Kodi na notebooku (Debian) a jel skvele. Oba jsme jej ovladaly mobilni aplikaci. Pak (cca pred dvema mesici) prisla velka aktualizace knihoven a vysledek je takovy, ze jemu jede porad perfektne a me se silne rozhasil zvuk. A nemuzu prijit na to kde je problem a jak to zpravit :(

4. 7. 2019, 21:08 editováno autorem komentáře

Zaujimalo by ma porovnanie vykonu toho arm procesora v raspberry pi 4 a nejakeho sucasneho x86 procesora napriklad od AMD alebo Intel. Mozem porovnavat flops cez linpack medzi inymi architekturami?

Jde to, třeba já mám dvoujádrový SandyBridge na 2,5 GHz (tady se HT nepočítá) a má mít teoreticky 40 GFLOPS a když to vyzkouším, dostanu 47 GFLOPS, asi pomůže turbo po tu krátkou dobu (15 sekund).

Porovnávat flops je doopravdy směrodatné jen u procesorů se shodnou instrukční sadou. U různých architektur je to silně zavádějí a porovnání mezi CISCem (x86) a RISCem (arm) neznamená zhola nic. Samozřejmě, že pokud má jeden řádově vyšší GFLOPS, než ten druhý, tak je rychlejší, ale porovnání dejme tomu 28 GFLOPS vs 34 GFLOPS nevypovídá prakticky o ničem.

Tak zrovna FLOPS z testu HPL se používají pro porovnání výkonů superpočítačů Top500 a tam se právě srovnávají různé architektury x86, power, sparc, nemluvě o GPU.

Srovnávat FLOPS tedy určitou cenu má i v případě rozdílných architektur, obzvlášť jestli nám jde o výpočty v plovoucí desetinné čárce, naopak třeba srovnávání jen pracovní frekvence mezi architekturami je zavádějící.

Atomy mají slabý FPU, jen 1,5 DP instrukcí za takt (A53 má 2 DP instrukce a A72 4 DP instrukce za takt, link v článku). Pak pro ten Atom x5-Z8350 vychází teoreticky 8,6 GFLOPS, tak to by s tím měřením souhlasilo.

Jaké to je s RAM, je celá k dispozici? Sice se mi v hlavě matně motá něco jako PAE, ale už je to sakra dlouho, co jsem obecně viděl nějaký 32b Linux na počítači s >=4GB RAM.

free vidí 3,81 GB, zbytek bude VRAM

Čistě teoreticky 2^32= 4,294,967,296. Takže teoreticky adresovat ~4GB jde. Samozřejmě záleží na mnoha faktorech.

PAE když tak jde použít, ale možná to není nutné.

Něco z RAM sežere GPU (vRam). To se nastavuje v:

/boot/config.txt gpu_mem

https://www.raspberrypi.org/documentation/configuration/config-txt/memory.md

Těším se na až to bude podporovat ubuntu-mate ARMv8 64-bit (Zatím je podpora jen pro RPI3).
To pak bude se 4GB hodně zajímaví.

https://ubuntu-mate.org/raspberry-pi/

4. 7. 2019, 09:22 editováno autorem komentáře

Na ARMu se to jmenuje LPAE…

Našel jsem, kde RPi Foundation vzalo ty Linpack benchmarky . Jde o trochu jiné matice a test je jen jednovláknový. Má tam sice verzi s více vlákny, ale jen pro Android. Binárky pro ARM32 a ARM64.

Asi jediná možnost, jak vyzkoušet HW dekodér HEVC je alfa verze LibreELEC. V Raspbianu to evidentně moc nefunguje – přehrání DVB-T2 vysílání se zaseklo po několika obrázcích.

To by mě zajímalo, jak má být ta HW akcelerace HEVC na RPI4B navlíknutá. Bude to třeba dostupné skrz VAAPI ? Týká se toho třeba nějaký driver grafiky ve vanilkovém kernelu? Jak se vůbec jmenuje GPU driver pro BCM2711 ? drivers/gpu/drm/vc­4/ ? Pořád ještě se to všechno tváří na první pohled jako BCM2835 / VideoCore4, přestože ve skutečnosti je to BCM2711/VideoCore6 ?

Škoda že to nemá na PCI-e rovnou taky SATA řadič.

Hm ono to vypadá, že pro VC5/VC6 je nový driver, který zatím není ve vanilce ani v GITu:

https://lkml.org/lkml/2018/4/19/838

tzn. drivers/gpu/drm/v3­d/

Viz též https://01.org/linuxgraphics/gfx-docs/drm/gpu/v3d.html

Jsem zkusil tu alfa verzi LibreELEC 9.1.001 a opravdu dekóduje HEVC hardwarově. Na medůzách přehraje až 120 Mb/p 10bit 4k, ten další 140 Mb/s a víc už není plynulý

Ještě jsem si všiml, že Kodi v menu, když se nic neděje, tak zatěžuje 20-30 % CPU, to tak má být?

Asi to tak nemá být, v Raspbianu Kodi zatěžuje CPU jen 3 %.

Teplota neni trochu, ale o dost vyssi. V klidovym stavu s tim pribalenym (malym) chladicem nejde pod 60°C.

to je v krabičce? bez krabičky s malým chladičem 55C

V krabicce (s malym chladicem) je na 65°C v idle. Uz jsem objednal ten vetsi chladic.

Na 54-56°C jsem s velkym chladicem (20x20x19mm) u orevreny krabicky (nezadeklovana). V idle, standardni Raspbian (cerstve nainstalovany, rebootly a po 10 minutach nicnedelani).

Tak ono v tychto letnych teplotach hodne pecie aj 3B+. V idle mam teraz 58°C (holy cip, bez akehokolvek chladicu, ale zavrety v ofiko krabicke).

Já sundal víčko krabičky, pomohlo. Takže jsem do něj (a do dna) udělal pár děr (aby tam někdo omylem nesáhl) a je to ok (to samé jsem udělal už dávno s RPi3).

muzes pridat "trochu" vetsi chladic ;-)
https://www.cnx-software.com/2019/07/05/raspberry-pi-4-cooling-fan/

Aktivni chladic !!! Pro mne neco co to Pi zabije.

tak pokud nekdo RPi4 chce zatezovat a/nebo mit z jakehokoliv nizkou teplotu je to reseni, pisu ze to stahne z 80C na 40C coz neni malo, takze predpokladam ze stazeni otacek vetraku pod slysitelnou mez(mozna i sundani vetraku) by porad aspon 20C stahlo :-)

Já jen dodám, že asi takový obrovský chladič nebude potřeba. Při testu hevc a hpl jsem na ten klasický 1 cm vysoký černý hliníkový chladič provizorně foukal USB větráčkem a teploty se taky snížily z 80 na 40. Teda pohyb vzduchu kolem i běžného chladiče má velký vliv.

Měl bych jen připomínku k /dev/random vs. /dev/urandom. A totiž že /dev/urandom není méně náhodný, ale je úplně stejný. Více viz třeba https://www.2uo.de/myths-about-urandom

Tak random a urandom nejsou úplně stejné. Random je náhodná sekcence a urandom pseudonáhodná sekvence jen se seedem z random. Z toho třeba plyne, že na systému se špatným random a tím pádem s málo entropií by se dalo urandom lehčeji uhodnout. Proto je HW rng důležitý i pro ty, kdo třeba z přesvědčení nebo kvůli rychlosti používají výlučně urandom.

random i urandom jsou CSPRNG. Bohužel je to tak, že je to právě naopak - /dev/random používají lidé třeba z přesvědčení, a nikoli na základě fakt.

Slidedeck: https://speakerdeck.com/filosottile/the-plain-simple-reality-of-entropy-at-32c3
Přednáška: https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy

TL;DR Používejte /dev/urandom. Jediný problém je early boot - použijte "getrandom()" nebo načtěte jeden byte z /dev/random.

Ano, toto je dost kontroverzní téma.

"random i urandom jsou CSPRNG":

Ale u /dev/random se ten CSPRNG používá jen místo "software whitening", protože prakticky každý HW RNG dává například více jedniček než nul. To může záviset třeba na teplotě a je to nežádoucí.

/dev/random ale vezme jen tu entropii, co do ní z HW nateče, tu transformuje, aby byla vyvážená a pustí do výstupu. /dev/urandom si entropii "domýšlí", když už na vstupu dojde. Proto je /dev/urandom v principu pseudonáhodný a /dev/random náhodný, i když používají stejný algoritmus.

Ne, na tomto tématu není nic kontroverzního. Prostě používejte /dev/urandom. urandom je CSPRNG, nic jiného Vás nezajímá a ani nemá zajímat. Doporučuje $(($RANDOM%5)) kryptologů z pěti.

/dev/random žádnou entropii nevyvažuje. /dev/random jen odhaduje kolik jí tak může být. Oba (/dev/random a /dev/urandom) zdroje totiž používají ten samý "pseudonáhodný" CSPRNG (Cryptographically secure RNG) s tím, že /dev/random umí blokovat, když počitadlo klesne příliš nízko. Jenže s výjimkou bootu to už je jedno. Jak byl jednou ten CSPRNG dostatečně naseedovaný, tak generuje sekvenci nerozlišitelnou od šumu.

Ještě jednou doporučuji si přečíst https://www.2uo.de/myths-about-urandom nebo alespoň ty citace na konci:
- https://www.mail-archive.com/cryptography@randombit.net/msg04763.html
- https://sockpuppet.org/blog/2014/02/25/safely-generate-random-numbers/
- https://security.stackexchange.com/questions/3936/is-a-rand-from-dev-urandom-secure-for-a-login-key/3939#3939

Toto téma není mezi odborníky kontroverzní ani trochu. Kryptologové doporučují na linuxu používat /dev/urandom.

Hwrng je důležité pro virtuální stroje, protože se dost typicky vytvářejí z šablon a mají velmi podobnou zátěž. Virtuální počítače také typicky nemají moc zdrojů náhodných dat (žádná klávesnice, myš, teplota, ..). Seed CSPRNG v takovém případě dostává shodná data při bootu a tudíž by mohlo dojít ke generování stejné sekvence třeba pro prvotní inicializaci soukromých klíčů ssh. Hwrng dodá každé VM jiná data z hosta a tím zajistí unikátnost.

To jsou ovšem věci, které nemají vliv na rozdíl /dev/random a /dev/urandom. Jednoduché pravidlo pro vývojáře aplikací je: Používejte /dev/urandom. Vždy a všude.

V případě Guest strojů je hlavně důležité použít <a href=“ https://fedoraproject.org/wiki/Features/Virtio_RNG”>VirtIO RNG a jsme zpátky jen u Early Boot problému. A pak samozřejmě takové blbosti jako nemít uložený stejný seed v image, kterou klonuju, atp...
Moje zpráva je (skoro) stejná jako ta Vaše - používejte /dev/urandom, případně ještě lépe getrandom() volání. A pokud potřebujete jedno stejné rozhraní na různých platformách, použijte crypto knihovnu (libcrypto, GnuTLS). Vždy a všude.

Utahne to USB 3 externí USB 3 disk?

asi záleží na zdroji a na disku, Transcend 2,5" 4GB s oficiálním RPi zdrojem jede

Vyplatí se přidat ty 3 stovky a jit do 4GB verze nebo stači 2GB?

tak záleží, víc RAM je víc Adidas, třeba pro /tmp atd.

Už je doma ta 4 GB :)