Názory k článku
MetaCentrum: grid s největší výpočetní kapacitou u nás

Heh, to jsem si ani nevšiml, že to je blbost na druhou. (Pro vyjádření počtu se obvykle používají čísla přirozená, nikoliv komplexní.)

"petabyte = 1015 B"
to mi připomíná doby dávno minulé, možná by tam bylo vhodnější dát 10^15 B :)

asi jim mistní publikační systém žere stříšky, viz (terabyte = 1012 B)..asi má být 10^12 B ne ? :)

10^x, jste se zbláznili :)? Od kdy pracují počítače v desítkové soustavě?

Petabajt je pro mě jedině 2^50 B.

Petabajt je 10^15 B - podle standardu SI.
Pocitace pracuji v dvojkove soustave, ale lidi pracuji v desitkove a vetsinou preferuji zobrazeni udaju v desitkove soustave.

Lepsi je precist si "na disku je 710934528 bajtu volneho mista" ve desitkove soustave nez "na disku je 101010011000000000000000000000 bajtu volneho mista" ve dvojkove.

A 2^50 B je pebibyte. Bohuzel, lidi casto pebibyte chybne oznacuji jako petabyte.

http://en.wikipedia.org/wiki/Pebibyte

http://en.wikipedia.org/wiki/Binary_prefix
"Current national and international standards state that traditional SI prefixes always refer to powers of ten, even in the context of information technology"

Pro mě bude vždy kilobajt 1024 bajtů (2^10) a ne 1000, a tedy petabajt je pro mě 2^50.

Promiň, ale snažíš se zbytečně, tohle začalo marketingovým překrucováním kapacit CD a HDD, a je nejvyšší čas, aby to i skončilo.

Děkujeme za upozornění, do článku byly opět doplněny horní indexy, které autorka pochopitelně uvedla, a které se "schovaly" během zpracovávání článku.

A kdyz uz jste u toho opravovani, tak sestnactijaderny se prosim pise 16jaderny (zdravime prof. Kroba, dekana FF MU).

Kolega Antoš? :)

Vy jste jeho kolega? A který?

Kterého? :) (Teď už se v tom nějak ztrácím, ten kolega byl myšlen hodně nadnešeně.)

Chtělo by to podrobnější článek. Mě osobně nezajímá jen HW, ale i SW, jak se jedna úloha rozdělí na takové mnoství rozdílných platforem (je možné jedním úkolem rozděleným na thready zatížit celý grid najednou?), jestli tam je nějaká vrstva, která zajišťuje kompatibilitu.

Taky by mě zajímalo zajištění proti výpadkům, co když vypadne CPU, jaké jsou strategie zálohování.

Jak se provádí kontrola výpočtů, jedna když nechám něco běžet na 1k procesorech... Je to čistě na aplikační vrstvě, aby si zkontrolovala správnost dat, a nebo se kontroluje HW i nějak interně a sám opravuje chyby a odstraňuje vadné bloky HW?

V principu je možné dobře napsanou aplikací využívat zároveň i stroje rozdílných platforem (existují komunikační knihovny, které to podporují), obvyklejší je ale využití podmnožiny strojů se stejnou architekturou, protože konverze dat mezi architekturami mohou brát část výkonu a při psaní aplikací je třeba s možnými rozdíly počítat (kromě konverzí binárních dat mohou přijít do cesty zvláštnosti různých operačních systémů, kompilátorů apod.).

Na zjevný výpadek procesorů za běhu aplikace upozorní aplikaci komunikační vrstva - část výpočetních procesů se přestane ozývat, jinak je to na aplikační vrstvě. Opravy malých chyb jsou u některého HW možné (ECC paměti, kontrolní kódy v síťových protokolech), ale obecně se toho u běžných PC serverů, které tvoří většinu HW zdrojů METACentra, bez spolupráce s aplikační vrstvou moc dělat nedá a výpadek je třeba řešit novým spuštěním aplikace (stroje, o kterých se ví, že mají HW problémy se zablokují v systému pro plánování úloh).

Takže v čem je tedy rozdíl mezi kupou různorodých počítačů (z nichž mají některé serverové desky a paměti) a gridem.

Jsem myslel, že v gridu bude minimálně nějaká SW vrstva (něco jako Java), která umožní rozdělit úlohy na všechny PC, a zajistí jistou jednotnost prostředí, ale ono to spíš vypadá, že jsou to jen "shluky" počítačových farem, které jsou seskupeny spíše formálně.

Je jediná výhoda v tom, že si člověk může požádat o výkon na jednom místě a nemusí prolézat různé formuláře (tedy výhoda administrační), a nebo existuje i nějaká jiná?

Takhle mi to připadá, že když si dám doma dohromady několik počítačů, tak si to můžu označit za grid. Jsem čekal aspoň nějakou mezivrstvu, aby člověk nemusel kompilovat aplikace pro každý typ HW, OS a SW...

Díky za reakci, tihle "žrouti" mě celkem zajímají :) (kde bychom byly bez nich, ani bych nevěděl, jestli bude zítra na horách sněžit).

Snad 16-ti jádrové, ne? :D

16jádrové :-)

Nás to baví :), proto ty úsměvy...

Ve skutečnosti ovšem 16 jádrové. :)

"MetaCentrum se dnes může chlubit celkem 994 jádry CPU v 335 strojích, což je zřejmě největší výpočetní objem v naší zemi"

Nemají ufouni (Seti@home) resp. u nás zapojené počítače celkem větší výkon?

Vy verite, ze se tim skutecne hledaji ufoni ? Ja tipuji, ze se tim louska cizi zasifrovana komunikace.

No vzdyt ano, ufounska :-)

Celkový výpočetní výkon dobrovolníků z ČR, na všech projektech pod BOINC, je cca 18 TeraFLOPS. Což bude 3-4x více než MetaCentrum. Je tedy jasné, že největší výpočetní objem u nás neposkytuje MetaCentrum, ale několik tisícovek počítačů provozovaných pod BOINC. Jen je obrovská škoda že tento potenciál nedovede žádné naše vědecké pracoviště využít.

Pravděpodobně se na takový projekt těžko tahají peníze z různých fondů? Co by asi kdo získal za grant, když by do žádosti napsal že má k dispozici tak velký výkon a skoro zadarmo :-)

Problém se systémy typu BOINC, Seti@Home a podobně je v tom, že jsou vhodné pouze pro jeden typ úloh, tzv. "embarrassingly parallel", tj. "paralelní až je to trapné", kdy je možné úlohu rozdělit na spoustu malinkých vzájemně nesouvisejících kousků. Ale existuje spousta úloh, kde to není možné, a při zpracování musí zpracovávající počítače spolu komunikovat, a někdy velmi rychle.

Nevím jestli sem to pochopil správně, ale metacentrum je na tom s výpočetním výkonem podobně jako BOINC. Pochybuji, že různé platformy od sebe dost vzdálené fyzicky, spolu dokáží komunikovat "velmi rychle"

METACentrum je propojeno rychlou sítí, viz http://meta.cesnet.cz/cs/resources/network.html
takže podle vybavení konkrétních uzlů a jejich vzdálenosti mohou komunikovat mezi 1Gb/s (Ethernet) a 20Gb/s (Infiniband).
Pokud uzky leží jeden v Brně a druhý v Plzni, hraje samozřejmě roli i latence, nicméně je možné při spouštění úlohy požádat například jenom o stroje v Brně.

Krome toho sit vyuzivajici domaci pocitace muze mit latenci klidne nekolik dni -- napr. kdyz se uzivatel rozhodne pocitac vypnout :-). Musi se tedy jednat o opravdu zcela nezavisle ulohy, kterym nevadi, ze je jedna cast spocitana za par hodin a jina za par tydnu.
A to se nedotykame jednotnosti prostredi, bezpecnosti atp.

Jen pro upresneni, v Plzni neni provozovan jen cluster Meta centra a ZCU spravovane Meta centrem, ale i cluster Hydra, ktery je ve vlastnictvi KIV ZCU ( http://meta.cesnet.cz/cs/resources/hardware.html#hydra-fr ) a ktery je i ve sprave katery KIV( www.kiv.zcu.cz ).

A nebo přímo sem:
http://scb.ics.muni.cz/static/

kdyz jsou v nem nektery node dole 350 dni :-) ....

Srovnávat výpočetní výkon Grid a Cluster řešení je zcela zcestné a nekoretní.

Grid provozovaný Matacentrem ani zdaleka neumožňuje jeho uživatelům využití všech dostupných výpočetních zdrojů jednou aplikací současně, což je přesně to, co výpočetní clustery (např. Amálka) umožňují. Z tohoto důvodu je výkonové srovnání Gridu Metacentra se superpočítačem Amálka jasně zavádějící. V tomto případě bychom totiž mohli tvrdit, že nejvýkonější výpočetní systém v České republice provozuje ten, kdo disponuje největším počtem dostupných výpočetních jader nebo CPU, která jsou navzájem síťově propojena . Pak by např. Česká pojištovna nebo Česká pošta byla provozovatelem mnohem výkonějších gridů než Metacentrum. Což, jak jistě uznáte, není pravda.

Pravdou je, že Metacentrum provozuje řadu různých výpočetních systémů využívajících různé OS, HW technologie a SW nástroje (tedy silně heterogenní prostředí), které jsou navzájem propojeny vysokorychlostní sití do Gridu s více či méně dostupným sdíleným diskovým prostorem. Žádný z těchto separátních výpočetních systémů ovšem nemůže výkonově konkurovat superpočítači Amálka a nemohou ani současně všechny provozovat jednu výpočetní aplikaci tak, aby se efektivně využil sumární výpočetní výkon gridu.

Faktem je, že Amálka je nejvýkonějším superpočítačem (výpočetním clusterem) v České republice, protože umožňuje prokazatelným způsobem provozovat konkrétní aplikace, které dokáží tento dostupný výpočetní výkon plně a dlouhodobě využívat. A to vše navíc v plně paralelním režimu, tj. v režimu, ve kterem mezi sebou mohou navzájem rychle komunikovat všechny procesy navzájem. Což je přesně to, co díky praktickému provoznímu scénáři a technickým omezením Gridu Metacentra není dlouhodobě (a pravděpodobně ani krátkodobě) vůbec možné.

Vše co zde uvádím není vůbec myšleno jako obhajoba superočítače Amálka vzhledem ke Gridu Metacentru, protože se jedná o výpočetní systémy s diametrálně rozdílným účelem pro který vznikly a jsou provozovány.

Smyslem mé poznámky je stále se opakující skutečnost, že autorka tohoto článku evidentně vůbec nerozumí tomu o čem píše a mistifikuje čtenáře zcela zcestnými tvrzeními.

Pokud si článek přečtete pozorně, pochopíte, že METACentrum má celkem cca 1500 (jader) CPU, z toho cca 1000 tvoří metaklastr a cca 500 je zapojeno v gridu EGEE.

V článku se hovoří především o oněch cca 1000 CPU, které jsou propojeny vysokorychlostní sítí, spadají pod jeden plánovací systém PBSPro, sdílí diskový prostor přes AFS, mají jednotnou správu uživatelských účtú, a jedná se v drtivé většině o Intel/AMD stroje s Linuxem, tedy poměrně homogenní prostředí.

Teoreticky si *může* uživatel METACentra spustit úlohu využívající všechny stroje začleněné v onom metaklastru, tj. na 1000CPU. Že se tak prakticky neděje je způsobeno tím, že METACentrum je tvořeno příspěvky více organizací a vlastníci konkrétních strojů na nich mají prioritu, takže taková úloha přes všechny stroje by čekala měsíce nebo roky, než by se uvolnily všechny stroje v jednom okamžiku.

Ovšem METACentrum je otevřeno všem zájemcům z akademické sféry, kdežto Amálku si její vlastníci syslí jenom pro sebe, a nikoho dalšího na ni nepustí. Je pak logické, že Amálku si může zabrat pro sebe jeden uživatel, kdežto v METACentru si uživatel může zabrat jen "svoje" stroje, a o stroje poskytnuté ostatními se musí s těmi ostatními dělit. Nicméně každá skupina uživatelů tak má v případě potřeby více strojů, než kolik činí její příspěvek do METACentra.