750 Raspberry Pi 3-ból épített clustert a Los Alamos National Laboratory és a BitScope

 ( trey | 2018. január 22., hétfő - 14:01 )

LANL’s challenge to BitScope was to build a 3000-core ‘pilot cluster’ as “a test bed for Los Alamos researchers to use to develop their own next-generation computers,” Bruce explains.

Részletek itt és itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A legszebb az egészben, hogy nem érinti a Meltdown/Spectre:

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

--
robyboy

Azért aki ezt a fenti szösszenetet írta, az sem olvasta át az egészet a végén...

Raspberry Pi 3’s extra performance is partly a result of improvements in branch prediction between Cortex-A7 and Cortex-A53. However, by executing a crafted series of branches, an attacker can mis-train a branch predictor to make poor predictions.

Tehát van benne branch predictor...

The branch predictor is used to choose the most likely path through the program, maximising the chance that the speculation will pay off.

...aminek a céja, hogy a spekulatív végrehajtás minél negyobb teljesítményelőnyt hozzon...

The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort.

...de nincs spekulatív végrehajtás?!

Nem ellentmondás ez egy picit?
---
Régóta vágyok én, az androidok mezonkincsére már!

Attól még csak nem muszáj össze-vissza végrehajtogatni az a kódot, hogy spekulatívan előtöltve figyel a vezetékben?

spekulatívan előtöltve figyel a vezetékben == megkezdődött a végrehajtása, a preload állomáson már túl van

Egyébként legvalószínűbb megfejtés az, hogy egyszerűen túl rövid a Cortex-A53 8 lépcsős pipeline-ja, hogy a sikeres exploithoz szűkséges két egymást követő adatfüggő read műveletből a második is eljusson az execute állomásig. Out of order végrehajtás híján a pipeline hosszánál nem is tud hosszabbra nyúlni a spekulatív ablak. De ezt még így nem láttam leírva sehol, szóval mérget ne vegyél rá. Mondhatni "spekuláció" :)
---
Régóta vágyok én, az androidok mezonkincsére már!

Ja, ez a legszebb a témában, hogy sok még mindig a köd.

Mostanában az Intel mintha pár naponta adná ki pl. az újabbnál újabb microcode-jait.
Ami nem is csoda, mert a hirtelen kiadott microcode-tól csomó gép restartolt álltólag.

--
robyboy

Én nem ezt látom. Egy pakkot adott ki szép csendben december közepén az Intel, amikor még nem volt publikus a sebezhetőség, meg kitolt egyet jan. 8-án. Legközelebb január végén ad ki, ezt nem nevezném pár naponta kiadásnak. Sok procit kell javítani, és lépcsőkben tolják ki az anyagot. Az egyik lépcsőt ismételni kell a restartok miatt (bár úgy tudom, hogy csak a windowsos gépeket érinti).


„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

A forrás lehet pontatlan. A Cortex A7 és A53 az Arm "gyenge" magjai. Mindkettő csak in-order cpu mag. Ezért nem érintettek.


Normális HUP-ot használok!

Ha alaposan végiggondolja az ember, elvileg az out of order nem is feltétlen szűkséges feltétele a sebezhetőségnek, tényleges végrehajtás-átsorrendezés sehol sincs kihasználva.
Inkább úgy helyes, hogy van olyan CPU feature, ami egyszerre előfeltétele az out-of-order végrehajtásnak és a spectre/meltdown sebezhetőségnek. De sorrendet nem kell felcserélni hozzá, csak késletetni kell a conditional branch eredményének visszaíródását (=spekulatív futás leállítását) amíg a második (szivárogtató) read is eljut az execute fázisig.

De persze ez inkább elméleti kérdés, nem hiszem, hogy lenne in-order CPU, ahol lenne olyan puffer a pipeline állomások között ami ezt lehetővé teszi.
---
Régóta vágyok én, az androidok mezonkincsére már!

'...de nincs spekulatív végrehajtás?!'

Pipelineban az execute a sokadik lepes, az utasitas beolvavas (fetch) nem jeleniti azt hogy
a vegrehajtashoz is eljut.
Valami gagyi branch bredictor nagyon regeta benne van a legegyszerubb proffeszorokban is (>=5-stage)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Alapvetően a szöveg önellentmondó megfogalmazására akartam felhívni a figyelmet.

Van olyan CPU, aminél van külön data fetch fázis az execute a pipeline-ban. Ha van valami prefetch engine és előre ismert a memóriacím (=nem a közvetlenül megelőző memóriaolvasás eredményéből derül ki, ahogy a meltdown-nál kell), akkor a memóriaolvasás sokkal korábban is megtörténhet, nem kell az execute-ig elérnie.
---
Régóta vágyok én, az androidok mezonkincsére már!

A branch predictor meg a spekulatív végrehajtás nem ugyanaz.
Az, hogy van benne branch predictor, az egy dolog.
Az meg egy másik dolog, hogy végrehajtja-e spekulatívan mindkét ágat.
Ugyanis branch prediction esetén csak akkor hajtódik végre mindkét ág, ha sikertelen prediction történt.

Míg spekulatív végrehajtás esetén akkor is végrehajtódik mindkét ág, ha sikeres a prediction.

Nem ugyanaz, de a branch predictornak mi lenne az értelme, ha nincs spekulatív végrehajtás? Mi az ami felhasználja a predikció eredményét?

És mi értelme volna végrehajtani mindkét ágat, ha sikeres volt a prediction?
---
Régóta vágyok én, az androidok mezonkincsére már!

"a branch predictornak mi lenne az értelme, ha nincs spekulatív végrehajtás?"
Van egy olyan géped, amiben egy darab pipeline vna, de az több stage-ből áll.
Hasznos, ha meg tudod mondani x% valószínűséggel, hogy egy branch melyik ágát kell végrehajtani, mert akkor nem kell megvárni, míg kiürül a pipeline, hanem lehet folyamatosan tölteni. Amikor félremegy a prediction, akkor ki kell üríteni a pipeline-t és a másik ággal futtatni.

Ha nincs branch prediction, akkor a branchelő kifejezés kiértékeléséig a pipeline-ba új utasítás nem kerülhet, hiszen mi kerüljön oda?

"És mi értelme volna végrehajtani mindkét ágat, ha sikeres volt a prediction?"
Nem sikeres volt, hanem sikeres lett. Nagyon nem ugyanaz a helyzet.
Legyen mondjuk B, U1 és U2 a branchelő, valamint a branch két ágának utasítása.
Ha van spekulatív out-of-order execution, akkor megteheti a gép a következőt:
U1 végrehajtása, majd U2 végrehajtása, majd b végrehajtása, majd u1 és u2 eredménye közül a megfelelő használata.

Simán előfordulhat, hogy ez azért történik meg, hogy b végrehajtása nem kezdődhet meg addig, míg egy másik utasítás végig nem megy a pipeline-on (adatfüggőség), de u1 és u2 végrehajtása mehet addig a pipelineban (mert azok nem függnek attól, amire B vár), nincs üresjárat, max eldobjuk valamelyiknek az eredményét.
Ez teljesítménynövekedést jelent ugye (minimalizáljuk az adatfüggőség miatti várakozásból bekövetkező üresjárást), cserébe van vele gond.

"The most common form of speculative execution involves the control flow of a program. Instead of
waiting for all branch instructions to resolve to determine which operations are needed to execute, the
processor predicts the control flow using a highly sophisticated set of mechanisms. Usually the
predictions are correct, which allows high performance to be achieved by hiding the latency of the
operations that determine the control flow and increasing the parallelism the processor can extract by
having a larger pool of instructions to analyze. However, if a prediction is wrong, then the work that
was executed speculatively is discarded and the processor will be redirected to execute down the
correct instruction path.
While speculative operations do not affect the architectural state of the processor, they can affect the
microarchitectural state, such as information stored in TLBs and caches. The side channel methods
described in this white paper take advantage of the fact that the content of caches can be affected by
speculative execution. "
Forrás: https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf

Amúgy ajánlom ezt a könyvet:
https://www.amazon.com/Advanced-Computer-Architectures-Approach-International/dp/0201422913
Megjelent magyarul is:
https://www.antikvarium.hu/konyv/sima-dezso-fountain-terence-korszeru-szamitogep-architekturak-295716

"Hasznos, ha meg tudod mondani x% valószínűséggel, hogy egy branch melyik ágát kell végrehajtani, mert akkor nem kell megvárni, míg kiürül a pipeline, hanem lehet folyamatosan tölteni. Amikor félremegy a prediction, akkor ki kell üríteni a pipeline-t és a másik ággal futtatni."

Amit leírtál az pontosan a spekulatív végrehajtás definícója. Ezt leszámítva szerintem nem mondunk ellent egymásnak.

"Nem sikeres volt, hanem sikeres lett."
Ok, itt én foglamaztam hülyén.

"Ha van spekulatív out-of-order execution, akkor megteheti a gép a következőt:
U1 végrehajtása, majd U2 végrehajtása, majd b végrehajtása, majd u1 és u2 eredménye közül a megfelelő használata."

Értem mire gondolsz, viszont ez tényleg egy már nagyon out-of-order feature és szerintem bőven túlmutat a spekulatív végrehajtás alap definícióján.
---
Régóta vágyok én, az androidok mezonkincsére már!

megint szegeny fluimucil abelke jutott eszembe..

+1 :-)

---
Science for fun...

Nem eri meg, 6 combosbabb pc megveri es olcsobb is.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Pedig direkt ki is emeltem:

"LANL’s challenge to BitScope was to build a 3000-core ‘pilot cluster’ as “a test bed for Los Alamos researchers to use to develop their own next-generation computers,"

:(

Ez egy tesztprojekt.

"Nem eri meg, 6 combosbabb pc megveri es olcsobb is."

6 combosabb PC-ben nem lesz 3000 processzormag. A lényege ennek, hogy polcról levehető eszközökkel tudtak építeni egy 3000 processzormagos clustert, ami nem foglal el egy komplett adatközpontot, nem eszik egy kisebb falunyi villanyt, de mégis szimulálni lehet rajta egy nagyobb cluster működését. A teljesítmény valószínűleg itt 20-ad rangú faktor.

Sokkal érdekesebb lehet, hogy míg egy 3000 processzormagos cluster beszereztetése, szerverterem építése, klíma, villany, UPS anyámkínja beteremtése mondjuk 1 év is lehet, ahogy ismerem a "hivatalok" működését, addig ezt ha megvan a "hogyan", akár néhány nap alatt le lehet bonyolítani.

--
trey @ gépház

troll on
Hát ha én 3000 processzormagot akarok szimulálni akkor fogok egy virtualboxot és elindítok rajta annyi vm-et.
troll off

Ès milyen vasat raksz ez alá, ami ezt elbírja? Pl. hány fizikai CPU-t?

--
robyboy

Nem a számítási teljesítmény miatt csinálták, architektúra-terveket (pl. interconnect logikák stb.) akarnak tesztelni.

LOL.
Hi-speedre ez semmi, arra a szimulacio is jobb.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Kiemelem a lényeget:

pl. interconnect logikák

És szigorúan imho, de a kolléga tippre valami olyasmit próbált neked sugallni, hogy a "hogyan működik" nem minden esetben egyenértékű azzal, hogy "mennyire gyorsan".

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

3000 nodes clusternben mi az amirol nem tudjuk 15 eve mit hogyan
kell csinalni, ha a mennyire gyarsan nem szamit ?

`interconnect logikák` testre nem kell 3000 nodos valamit epiteni,
foleg ha sebesege kozeleben sincs a tenyelges valaminek.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Én nem tudok válaszolni az első kérdésedre, ezért nem is teszem azt. Te meg nem tudod, hogy ők (azaz akik a málna-klaszter mellett dntttek), miért ezt tették. De velem ellentétben ugyan nem tudod, de mégis megmagyarázod, hogy hülyék.

Lelked rajta.

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Tul sokszor lattam, hogy .gov (,.edu) berhuazasok nem feltetlen a leg kotlseghatokonyabbak.

Ez inkabb tunik egy hobby/tanulo projectken ott ahol van sok penz,
mintesem egy tenyleges merfoldkonek barmiben..

Nem feltetlen hulyek, csak azert mert megtudtak gyozni a penz forrast,
hogy tamogassak egy cool projectet, tanulas celjabol, ami
adott esetben meg jo is valami masra is.

Lehet csak irigy vagyok a koltsegvetesre ;-),
ill. nem derult ki az irasbol, hogy pontosan miert is ez a legjobb mogoldas.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

OFF, de hátha jó helyen kérdezem.
Android-ot, vagy Yocto-val Linux-ot szeretnék építeni elfogadható, mondjuk 1 óránál rövidebb idő alatt. Ehhez kellene saccra olyan 25-30000 PassMark-nyi CPU teljesítmény. Van olcsóbb megoldás, mint i9-es gépet építeni?

Ha bérelsz gépet? Virtuális gép, do-nél. 1 dollár 1 óra 32 magos procira (64G rammal).

Hm. Mi az a "do"?
Most nézem, hogy az azure-on 32 magos virtuális gép $1.433/hour. Hm.

Köszi!

Köszi, 15 dollárt rászántam, hogy kipróbáljam a DigitalOcean-t.
Sajnos a honlapjukon is hirdetett 32CPU, 64G RAM, 1$/óra a valóságban nem elérhető. Létezik helyette ugyanannyiért 24CPU, 128G RAM, de 15$ feltöltéssel csak a 4CPU, 8G RAM-os gépet tudtam kipróbálni. (Az csak $0.06/hr, úgyhogy most van vagy 250 órám állatkodni.)
A cpuinfo szerint Xeon E5-2650 v4 van benne, vagyis valószínűleg azért 24 magos a legnagyobb virtuális gép, mert akkor megkapok egy egész fizikai procit. Viszont az internet szerint ennek a procinak csak 16000 körüli a PassMark pontszáma. Na majd meglátjuk, mire lesz elég.

Amúgy gyors teszteléssel elég jó számokat kaptam.
A 4-szálas Linux kernel fordítás 225 mp körüli (ld. még itt). A `phoronix-test-suite test build-linux-kernel` pedig 244 mp-et ad ki.

AMD Ryzen olcsobban johet ki, de az alaplap gyakran dragabb. Erdemes dobni egy matekot vele is.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Biztos vagy ebben?
Ez a gép képes 750 h.264 kódolású HD csatorna dekódolására párhuzamosan. 6 combosabb pc is megbirkózna ennyivel, azaz pcnként 125 HD csatornával?
Én ebben nem vagyok annyira biztos.


Normális HUP-ot használok!

https://devtalk.nvidia.com/default/topic/987460/nvdec-cuda-nvenc-speed-comparison/
6~7x GPU meg mindig olcsobb es elfer kevesebb es olcsobb pc-ben is,
ha h.264 minden almod. De lehet hogy meg ettol is van jobb megoldas..


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

"For example encoding on GTX 1070 in FHD quality to H264 will run 650 FPS"
Legyünk megengedőek és vegyük ekvivalens feladatnak 125 FHD videó párhuzamos dekódolását 125 FHD videó egymás utáni dekódolásával. De nem ekvivalens.
Ebben az esetben is csak 5,2 fps videókból tudna 125öt időben dekódolni. Szóval kellene 5 GeForce egy PC-be hogy meglegyen a minimális 25 fps. Csak itt jön a következő probléma, hiába van 5 darab Geforce egymás mellett, azért a dekódoláshoz szükség van CPUra is, hozzá kell férni a központi ram tartalmához és a hálózatról vagy háttértárról a videók forrását is el kell érni valahogy. 5 Geforce pedig egymás elől fogja elvenni az I/O-t. Második probléma, nem sok PC-be lehet öt darab Geforce kártyát betenni. Amelyikbe meg lehet az annyiba kerül, hogy sokkal drágább lesz mint ez a RPI3-as cluster.


Normális HUP-ot használok!

Összekevered a dekódolást meg az enkódolást.

Ha postolás előtt vetted volna a fáradtságot, hogy kattints a hivatkozott linkre láthattad volna mekkora butaságot írtál. Ezért talán nem is kattintottál volna a beküldés gombra.


Normális HUP-ot használok!

Hogy értsd: A GTX 1070 650 FPS-sel enkódol full HD H.264-et, nem 650 FPS-sel dekódol.

"Ebben az esetben is csak 5,2 fps videókból tudna 125öt időben dekódolni. Szóval kellene 5 GeForce egy PC-be hogy meglegyen a minimális 25 fps."
Nem, nem dekódol, hanem enkódol egyidőben 650 FPS-sel.
Azaz egyidőben 5 db GeForce kártya 25 fps-sel 650 full HD videót tudna enkódolni.
Nem dekódolni.

Az egész infó, amit linkeltél, nem full HD dekódolásról, hanem enkódolásról szól.
Viszont te mindenhol dekódolásról beszélsz utána. Na, ez a butaság.

Egy raspberry pi hány FPS-sel enkódol full HD streamet?

Újra _FAIL_ !!
Ha nem tűnt volna fel nem én linkeltem a hivatkozott forrást. Mivel nekem szólt a válasz viszontválaszoltam rá. Különben kódolásról és dekódolásról egyaránt ír a forrás. Számok is vannak mindkettőhöz.
A számolás láthatóan egyáltalán nem megy neked. Ezt jobb ha hagyjuk.

Nem foglalkoztatott eddig az enkódolás RPi-n, de most csak a te kedvedért utánanéztem:
https://www.reddit.com/r/raspberry_pi/comments/5677qw/hardware_accelerated_x264_encoding_with_ffmpeg/

Máskor ne akarj fogalom nélkül kioktatni, mert rád ég a dolog! :-)


Normális HUP-ot használok!

FULL HD -ra valoban versenykepes a Pi3, kerdes
hogy mit tud kezdeni a kitomoritett anyaggal a displayre valo kitolason tul.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Van olyan felhasználási terület ahol ez éppen elég. És itt nem egy tömeggyártású szériáról van szó. Én a "6 combosbabb pc megveri es olcsobb is" állításra reagáltam, mert az így általánosan nem jelenthető ki. Van sok feladat ahol hatékonyabb 6 combosabb pc de vannak olyan felhasználási lehetőségek is amikor ez a Raspberry Pi cluster hatékonyabb.

Full HDt nem kell lenézni. A magyar tévészolgáltatóknál ma is csúcsminőség a Full HD, amit sok csatorna nem érdemel meg ezért csak SD-ben megy digitálisan is.


Normális HUP-ot használok!

Van valami megoldás arra ha egy napon belül a 23-as, 234-es és 749 -es számú rpiben gajjra megy az sdkártya? :)

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Persze, odaküldik a gyakornokot, hogy cserélje ki :)
--
openSUSE - KDE user

Vagy az egesz PI-t.
Amugy egy 3000 nodes PC (rack mount server HW) eseten sincs mas erre.
HW komponens cseret nehez virtualizalni.

Legjobb esetben sd kártya sem kell. Újabban egy ideje már tud a rpi3 bootolni sd kártya nélkül is, mondjuk hálózatról. Más kérdés, hogy local storage a projekt szempontjából érdekes-e, avagy sem.

Kb. fél éve (?) már van netboot a Pi3-k FW-ében. A Unix világ meg ismeri már egy ideje a diskless workstation fogalmát és a hozzá tartozó technológiákat, valószínűleg már Linuxszal is lehet ilyet csinálni ;-)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Az első mondat sokaknak új infó, köszönjük. *törölve*. :)
--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead