První dny s CuBoxem

6. 6. 2012 | Luboš Doležel | Recenze | Hardware | 7274×

CuBox je miniaturní počítač izraelské firmy SolidRun. Jak je u podobných výrobků zvykem, je postaven na platformě ARM - stejně jako populární a bohužel obdobně těžko dostupný Raspberry Pi. Než se ale dostanu k napsání plnohodnotné recenze včetně všech možných benchmarků, dovolte mi vás navnadit a přiblížit vám mé první dny s CuBoxem poněkud odlehčenější formou.

Obsah

• Stručně o hardwaru
• První boot
• Jen blázen by si vybral Gentoo
• Hardwarová akcelerace
• Zvukový výstup
• Co bude v recenzi

Stručně o hardwaru

Abych vás nenutil hned zkraje odcházet na web výrobce, shrnu vám hlavní rysy CuBoxu.

Na rozdíl od Raspberry Pi dostanete svůj miniaturní počítač v černém plastovém obalu, není tedy „nahý“. Na zadní straně najdete vstup pro napájení 5 V, HDMI výstup, dva USB porty, eSATA port, slot pro kartu microSDHC a 1 Gbit/s ethernet port včetně indikace provozu. Zboku můžete vidět S/PDIF výstup, microUSB port a zpředu pak IR příjmač a červenou diodu indikující zapnutí.

Uvnitř krabičky se skrývá následující (základem je Marvell Armada 510 SoC):

• 800MHz procesor ARMv7,
• grafický akcelerátor Vivante GC600 (podpora 2D i OpenGL ES 2.0),
• vMeta HD Video Decoder na 500 MHz s podporou H.264 při 1080p30,
• 1 GB RAM DDR3 (pro systém ve výchozím stavu zbývá 620 MB, zbytek jde grafice)
• a ještě více.

Spotřeba samotného zařízení (bez napájení USB portů) by se měla vejít do 3 Wattů. Jako zavaděč je použit obvyklý U-Boot, který umožňuje boot nejen z SD karty, ale např. i z USB disku nebo sítě.

První boot

První boot byl dosti neveselý. Přístroj jsem zapojil, ale po spuštění mi na monitoru jen krátce problikl kurzor konzole a pak už bylo jen černo. Připojil jsem tedy CuBox k notebooku pomocí kabelu od mého telefonu. CuBox má sériovou konzoli dostupnou hezky pohodlně přes port microUSB, takže s příslušným modulem v jádře pak už stačí udělat jen screen /dev/ttyUSB0 115200.

Po chvíli zkoumání přes sériovou konzoli jsem zjistil, že framebuffer konzole funguje dobře, a to na FullHD rozlišení. X.Org ale na tom samém rozlišení naběhnout nechce – s mým monitorem HP se dostane do neshod: 1920x1200 totiž HDMI transmitter na CuBoxu neumí a na 1920x1080 se nepochopitelně pohádají. Prozatím jsem rozjel nouzových 1280x1024. Mimochodem, s televizí funguje CuBox na první pokus a hned si můžete ozkoušet, že Firefox a další věci na tom fungují dostatečně rychle.

Protože hodlám používat CuBox jako tenkého klienta s pár fígly (tzn., že takové přehrávání videa bude probíhat lokálně), hned jsem zkusil spustit X -query $xdmcp_server. Xka naběhla, já jsem se úspěšně přihlásil, ale hned po naběhnutí vzdáleného Xfce Xka spadla na kontrole paměti v Glibc. Něco je někde špatně. Po další zábavě, která vypadá takto:

root@cubox:~# pidof X
473
root@cubox:~# killall X
X: no process found
root@cubox:~# pidof X
473

jsem toho předinstalovaného Ubuntu měl plné zuby a rozhodl jsem se přejít na něco jiného, co bude hlavně rychlejší. To Ubuntu totiž mj. softwarově emuluje floating point operace (softfp), i když to tento hardware umí i pomocí koprocesoru (hardfp).

Jen blázen by si vybral Gentoo

...na tak pomalém zařízení. Inu posuďte a sami se svým počítačem srovnejte, v jakých výkonnostních relacích se tu pohybujeme – výsledky z Ubuntu:

# openssl speed md5
Doing md5 for 3s on 16 size blocks: 394652 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 351976 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 265930 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 134109 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 23876 md5's in 3.00s
OpenSSL 0.9.8k 25 Mar 2009
built on: Tue Jan 31 12:12:13 UTC 2012
options:bn(64,32) md2(int) rc4(ptr,int) des(idx,risc1,4,long) aes(partial) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5               2104.81k     7508.82k    22692.69k    45775.87k    65197.40k

Na druhou stranu je Gentoo vlastně dobrá volba, protože právě na takové herce se bude každá optimalizace hodit. Zásadní je nenechat CuBox v kompilaci napospas.

Prvním krokem bylo vytvoření crosskompilátoru na domácím (podstatně výkonnějším) serveru. Pak jsem na serveru rozbalil Gentoo stage3, vyexportoval ji přes NFS (nebudu kompilovat na pomalé SD kartě), na CuBoxu jsem se chrootnul a zkusil jsem první emerge. Tak pomalou kompilaci jsem už hodně dlouho neviděl – připomnělo mi to, když jsem jako osmiletý kluk proháněl MSVC++ na Pentiu 1 na 166 MHz. Ale teď CuBoxu trochu křivdím – než P1 rychejší je a hlavně má víc paměti.

Bohužel ani distcc v pump režimu se neukázalo býti přijatelně rychlé. Pak jsem zkusil qemu-arm a užitečný nástroj proot. Kompilace pod QEMU běží rychleji než nativně na CuBoxu. Navíc mi na serveru nedochází paměť, a tak se vyhnu zběsilostem jako swapování na flash disk (zdravím Windows a jejich TurboBoost) nebo na NBD (Network Block Device). Dalším řešením ale bylo sestavení jednoduchého skriptu, který spouští emerge v režimu crosskompilace. Za chvíli jsem takto ale systém dostal do stavu, kdy spuštění Bashe vyvolalo reakci Segmentation fault.

Teď už raději zase kompiluji přes noc přímo na CuBoxu, než pak muset hasit, co se kde pokazilo (co jsem kde pokazil).

A zatímco se Gentoo kompiluje, tak já přemýšlím, co mě vlastně čeká... OpenSSL z Gentoo stage3 dává tyto výsledky:

# openssl speed md5
Doing md5 for 3s on 16 size blocks: 506864 md5's in 3.00s
Doing md5 for 3s on 64 size blocks: 443697 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 316080 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 147246 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 24673 md5's in 3.00s
OpenSSL 1.0.0g 18 Jan 2012
built on: Wed Mar  7 20:58:12 Local time zone must be set--see zic manual page 2012
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) 
compiler: armv7a-hardfloat-linux-gnueabi-gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -O2 -pipe -march=armv7-a -mfpu=vfpv3-d16 -mfloat-abi=hard -fno-strict-aliasing -Wa,--noexecstack
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5               2703.27k     9465.54k    26972.16k    50259.97k    67373.74k

...což je znatelné přilepšení.

V jednu chvíli jsem si už myslel, že jsem poškodil ethernetový port nešetrným vytažením kabelu. Nakonec se jen ukázalo, že port je trochu háklivý na zapojení drátů – asi to mám v téhle zásuvce nějak divně (ale notebooku to vůbec nevadí), v jiné to už zase funguje.

Hardwarová akcelerace

Hardwarová akceleraci je důležitou věcí, pokud chcete na CuBoxu dělat něco víc než jen brouzdat po webu. Hardwarově je zde akcelerována 2D i 3D (OpenGL ES) grafika, stejně tak jako různé formáty videa (až do 1080p H.264), formáty obrázků (např. JPEG), ale i zvukové formáty.

Toť výcuc z informačního letáku a dalších „datasheetů“. Podstatné je, kolik toho out of box vlastně bude fungovat. Na Ubuntu asi rozchodíte akceleraci videa přes GStreamer (i když jsou na to dost stížnosti), ale na Gentoo mě všechno bude čekat od píky.

Prvním cílem je tedy rozchodit akcelerovaný framebuffer dovefb pod X.Org. Druhým cílem je mít fungující akceleraci videa pod MPlayerem, resp. FFmpeg. To bohužel znamená stát se programátorem a funkčnost si sám dopsat nad proprietární knihovnou od Marvellu. Při pohledu na větev (fork) XBMC s nově doplněnou podporou vMeta HD to ale nebude tak složité.

Ovladač dovefb není v Gentoo Portage. Asi je to proto, že je vyvíjen externě, a to zjevně v rámci projektu OLPC. Snad nebude padat.

Věci jako akcelerace dekomprese JPEG nebo třeba Vorbis OGG už beru jako naprostý bonus a pokud to náhodou implementuji, tak to už se budu sám plácat po ramenou.

Zvukový výstup

CuBox má i zvukový výstup. Technicky má možná ten nejlepší možný zvukový výstup (optický S/PDIF), ale pro praktické použití to není úplně ono. Neboli sluchátka na to napřímo nepřipojíte a pokud ani váš monitor neoplývá zvukovým výstupem (z HDMI), tak nezbývá, než si sehnat nějaký ten převodník.

Já jsem zavítal na eBay a tam jsem hnedle nějaký našel. Akorát budu mít na stole místo jedné černé krabičky hnedle dvě. Nevadí. Pořád je mi to milejší než velká hučící bedna a nepříjemný účet od ČEZu... Zatím tedy čekám na zásilku z Hong Kongu.

Co bude v recenzi

V recenzi ozkouším jak původní Ubuntu, tak jiné (komunitně) nabízené systémy a jejich vhodnost ke každodennímu použití. Neopomenu i nějaké ty open source OpenGL hry a jejich výkon. A když už mám doma kino na bázi XBMC, tak otestuji, jak dobře by CuBox nahradil můj stroj postavený kolem NVIDIA VDPAU.

Zajímá mě ale i výkon ethernetového portu. Ten je oproti stomegabitovému portu na Raspberry Pi gigabitový, otázkou je, co hardware skutečně zvládne přenášet.

       

Komentáře

[Michal Ludvig]

Pěkné, docela podobné mému TrimSlice Pro. (i když ten je samozřejmě hezčí :)

Další vývoj odhaduju takhle: pár dní si s tím budeš hrát, párkrát to přeinstaluješ, ale za týden, dva zjistíš že to je fakt moc pomalý na prakticky jakoukoliv činnost a skončí to v šuplíku. Resp v mém případě ve skříni ;)

[BFU]

Sheeva co tam je je skutecne uz zastarala vec

[BFU]

Btw na i.MX6 sabrelite nema ani tvoje Trimslice Pro (tudle, mam ho delsiho a docuram dal )

[Jaja]

Mohu jen potvrdit. U mě podobně dopadl Raspberry Pi... Mimochodem, kdyby měl někdo zájem, tak klidně prodám.

[Konqui]

Ozvi se mi prosím na email/jabber. Díky

[Jaja]

Poslano. (mel jsem jen jeden)

[prqek]

A ten při tom má GPIO piny, což ho, alespoň pro mě, činí o dost zajímavějším než tohle. Bral bych ho od tebe, ale už je pozdě, co?

[James Scott]

Jo taky bych ho klidně bral :) kdyžtak mail..

[multi]

doufam, ze si jich nakoupil vic, taky si jeden vezmu

[Mrkva]

Fakt? Já už plánuju 3D LED krychli alespoň 8x8x8 ovládanou přes net (a možná i něčím jako 3D tetris, 3D breakout a 3D space invaders :)

[Jendа]

Zkus si piškvorky v krychli nebo rovnou v hyperkrychli. Co třeba tic-tac-toe v 3⁶? A co na to teorie her? Je to hra vyhraná?

(zdroj inspirace: KSP)

[Dreit]

To já uvažoval taky nad 8x8x8 3D krychlí, ale pouštěl bych tam muziku - teď nevzpomínám jak se tomu říká, prostě by to bylo jako osm bargrafů vedle sebe, co sloupec, to určitá frekvence. Akorát tohle by mělo navíc historii, frekvence posunování by byla nastavitelná - takže to vlastně jakoby pořád pojede

[Mrkva]

Jo, taky je to v plánu :)

[Luboš Doležel (Doli)]

Psal jsem, že to chci používat jako tenkého klienta...

[David Watzke]

ale za týden, dva zjistíš že to je fakt moc pomalý na prakticky jakoukoliv činnost a skončí to v šuplíku

Díky této skutečnosti existuje tenhle článek Z tohodle důvodu (resp. proto, že mi to bylo v zásadě k ničemu) jsem CuBox Dolimu prodal.

[alblaho]

Je to pomalé i na "domácí NAS"?

[David Watzke]

To nevím, disk přes eSATA jsem k tomu připojovat nezkoušel. Doli by to mohl zkusit.

[realista]

jako NAS pres eSata je to vhodne. Samba max cca 25Mbyte/s cteni z NAS (zapis trosku pomalejsi ale porad pres 20) FTP zápis na NAS cca 50Mbyte/s! Cteni cca 23Mbyte/s kopírování přes SSH (winscp) cca 13Mbyte max.

Tedy to umi to co jsem potřeboval...do skříně to nepůjde.

[alblaho]

Dík.

[Petrik_CZ]

Tech 13MBps je omezeni winscp, vic jsem z nej nidky nevytahnul a to ani mezi dvema rychlejma strojema. Mezi dvema linuxama neni problem dosahnout pomoci 'scp' klidne 90MBps, pouziti sifry arcfour ulevuje CPU.

[alblaho]

Musím si konečně pořídit gigabitový switch

[petr_p]

Jak je to s OpenGL? Dekomprese videa proprietárním koprocesorem je záležitost uživatelského prostoru. Ale přístup k OpenGL je přes jaderný ovladač. Je ten otevřený, nebo je to také blob? Já se strašně bojím, že za rok za dva přestane výrobce tento čip podporovat, takže budeš postaven před volbu jestli přijít o OpenGL nebo neaktualizovat jádro.

[Luboš Doležel (Doli)]

Taky blob. Ale jen tak mezi náma, IDA Pro z podobných jaderných blobů s trochou snahy dělá hezký C kód

[Lukas]

hmmm pekne, hledam neco co bude mit hdmi port, gigabit ethernet port, mSD a USB, budete fan less a zvladne to prehravat (staci DLNA) 1080p na TV. Nic jineho. Testoval jsi to uz?

[Luboš Doležel (Doli)]

Tohle by to mělo zvládat už teď s XBMC. Obecně jediná věc, co tomu stojí v cestě, je software, hardware by tu už byl.

Ale jak je z článku asi jasné: zatím to není zrovna pro úplné BFU.

[Lukas]

Na webu pisou, ze v pohode da h.264 s datovym tokem kolem 10mb/s, coz mi prijde dost malo, vetsinu h.264 mam s podstatne vetsim datovym tokem. Docela dost mam take untouched remuxu a tam je datovy tok kolem 35 - 37 mb/s jenom video stopa. Dalsi otazkou je jestli to da po siti, kdy musi procesor obsluhovat jeste sitovku.

[Luboš Doležel (Doli)]

Myslím si, že typické ripy se do 10 Mbps vejdou. Víc vídám jen v satelitních streamech a tam je to dané spíš neefektivitou kódování.

[jímkasociálníspodiny]

Pozor ale, aby těch 10Mbps nebyl průměr. U videa je ten tok dost variabilní, špičky budou klidně 20 Mbps i víc. Třeba scéna s ohňostrojem, to bývá maso.

TV vysílání naopak špičko moc nemá, z logických důvodů, tam by většinou mělo 10Mbps stačit, protože ti mezuláni se obecně stačí stlačit bitrate ještě mnohem níž.

[kokan]

Zkuš něco rychlého a predkompilovaného třeba distro ArchLinux ARM. Myslím, že i lidí je kolem toho hodně .. a když něco není tak je tu AUR (nevím, jestli i pro ARM)

• http://archlinuxarm.org/

[gramo]

Jsem moc zvědavý na výsledky na síti coby handmade NAS. Kolik vytáhne na gbit síti při přehrávání více video souborů z více disků na USB? Díky za test ;)

[Jaromír Svoboda]

Obávám se, že USB bude brzdou. USB 3.0 ten CuBox nemá?

[David Watzke]

Ne, ale má eSATA (3 Gb/s).

[gramo]

Jasně, na data náročná na rychlost (povětšinou asi upload, třeba záloha celého notebooku, kde to budu chtít mít co nejdřív hotový, abych mohl jít o dům dál), tam bude e-sata ideální. Na běžné věci typu sledování filmu, poslouchání hudby, uložení tří office dokumentů, USB 2.0 bohatě bohatě stačí (reálně tak 200mbit pro usb a fullhd film má max. 50 mbit?). Otázka je jestli to cubox vůbec zvládne. Jsem opravdu zvědavý, kolik vytáhne, když bude zapisovat na esata a k tomu zároveň číst ze dvou usb, kolik to hodí do rychlostí. Jestli to bude v rozumných mezích hned objednávám :)

[Michal Ludvig]

Obavam se ze vsechno stejne pujde pres procesor. Pomala pamet, mizerne DMA, zadny network offload, ale pekne po staru precist, zpracovat, poslat dal. Sice to muze mit eSATA nebo USB 3.0 nebo GigE sitovku, ale temer jiste to ani jedno z toho nedokaze zivit plnou rychlosti. Natoz pak rychle soupat data mezi dvema takovymi periferiemi.

Asi takhle - muzu mit Ferarri ale ve meste plnym semaforu a jinych aut s nim 300 km/h stejne nikdy nepojedu.

[hw]

Tak to se obáváte špatně. Samozřejmě tedy záleží jak dokáže SW využít možnosti HW, to znamená jak dobře/špatně jsou napsané ovladače. Samotný 88AP510 po hardwarové stránce toho zvládne hodně (předpokládám hodiny 800 MHz):

• Řadič paměti je rychlý více než dost s maximální datovou propustností 1,5 až 4 GB/s podle typu a šířky připojené paměti. Samozřejmě umožňuje multi-port přístup s maximálním využitím šířky pásma.
• Maximální propustnost interní AXI sběrnice je ~3 GB/s.
• Všechny rychlé periférie jako třeba Ethernet MAC, SATA řadič nebo řadič displeje obsahují vlastní jednodušší řadič DMA umožňující přenosy pouze mezi danou periférií a pamětí.
• Dva obecné DMA řadiče schopné vytvořit až 4 paralelní DMA kanály.

Samozřejmě, při některých úlohách bude limitujícím prvkem CPU, ale ve skutečnosti bude počet takových nasazení celkem malý. 88AP510 obsahuje dost různých off-load periférií pro různé výpočty, šifrování apod. Otázka je, jestli implementace Linuxových ovladačů využívá všechny možnosti hardware.

[Petr Ježek]

A to je teorie nebo zkušenost?

[realista]

jak už jsem psal výše.. na NAS je to ok. Nejlepší výsledek jsem naměřil cca 400mbits při kopírování z CuBox /esata disku přes ftp.

[Juraj]

Mam stary server Celeron Coppermine s 512 MB RAM a Gentoo to zvlada kompilovat bez pomoci (dokonca aj zveriny typu libboost), len pred emergovanim treba zastavit sluzby nenazrane na pamat typu deluge-torrent (apache/postfix nerobi problem). Samozrejme, viem ze keby som tam chcel kompilovat Firefox/LibreOffice alebo cokolvek s Qt tak narazim.

[tomo_tn]

Jo jo kompilacia je vzdy len otazkou casu odkompilovat sa da takmer vsetko na akomkolvek HW mladsom ako 10 rokov. Problem nastava len ked to co kompilujes potrebujes aj co najskor pouzivat...

[R]

Ten Celeron je v OpenSSL 2- az 3-krat rychlejsi. Aj stary Celeron 433 (Mendocino) je rychlejsi ako toto.

[Stanislav Brabec]

Když jsem kdysi používal Gentoo, tak mi to v pohodě zkompilovalo na podobném stroji i KDE. A netrvalo mu to ani týden. Zaplatit >>10kWh za vlastní kompilaci KDE, to se přece vyplatí!

A kernel si zkompiluji na ARMovém PDA s 64MB RAM za pouhých 5 hodin a několik Wh.

[Elch]

Díky za recenzi, ve skutečnosti se poslední snažím přijít na to, který z ARM based micro computerů si koupím. Hledám něco na hraní s Linux kernelem na ARMu. Ideální by bylo i něco s JTAG interface abych si mohl zablbnout i s bootloaderem, ale zatím jsem neměl štěstí.

[Michal Ludvig]

Myslim ze vetsina ARM boardu ma JTAG i kdyz v nekterych pripadech tam mozna neni konektor, nebo jako v pripade TrimSlice tam sice je konektor ale jeste je potreba jakysi prevodnik na standardni JTAG. Konec koncu i spousta PC desek ma neco na zpusob JTAG ;)

[Tomáš Janovský]

Docela se mi to líbí a rád bych to koupil ale momentálně jsou vyprodaný (což bych si počkal), ale chtěj 30 Euro za doručení. Nechcete se někdo přidat, abychom koupili víc kusů najednou, ať se to vyplatí? Jsem z Prahy, takže bychom si to mohli potom v Praze předat (ať neplatíme ještě českou poštu).

Tak co Pražáci, nebyl by zájem? tomogo@seznam.cz

[Tomáš Janovský]

Ještě dodám, že to je výhodné od více kusů, ceny s dopravou:
1ks - 1*99+30=129 EUR
2ks - 2*99+50=248 EUR
3ks - 3*99+58=355 EUR
4ks - 4*99+65=461 EUR
5ks - 5*99+70=565 EUR
od 6ks je doprava vždy jen 70 EUR Tak směle do toho

[kotyz]

Skvělý by bylo udělat přímý porovnání s Raspberry Pi, pro lidi co se rozhodujou co koupit.