Ostatní diskuse k projektu

[Horvi]

Mě by se taky líbil novej, ale nezavrhoval bych paušálně použité. Realita je taková, že spotřebu není třeba příliš řešit, alespoň ve Vimbau, naopak potřebujem ECC, přes to nejede vlak, tedy jestli chceme Intel tak jedině Xeony (1155 nebo 1150) u AMD blahé paměti to zatím příliš omezené není, pak je potřeba vybrat desku co to opravdu umí, paměti, case a už v tom lítáme za 15-20k, tak tak

[ETNyx]

A jaká konfigurace serveru by byla potřeba?

[forest]

Server už bych nechal na astonomickém ústavu UK. Na srazu jsme se shodli na tom, že už jim s projektem nemáme moc jak pomoci, tedy krom aplikace pro grafiky a že by bylo rozumné, jim to celé v nějakém časovém úseku předat do správy. Nový server nechť si pořídí z grantu, jen jim můžeme doporučit parametry, aby byl do budoucna dostačující.

Měli by jsme se od toho trochu oprostit, aby vzniknul prostor pro případný další projekt, kterému by jsme mohli pomoci na svět. Tedy i vyklidit současný server pro potřeby nové a nebo jim ho předat a nějakým způsobem získat nový.

[Martin Tomasek]

Za dva dny začíná challenge na Asteroidech. Nepřihlásíme se taky? http://boincstats.com/en/stats/challenge/team/chat/400

[Michal Kinďura]

Za tři dny Primegrid

[nenym]

Osobně vysoce preferuji PG turnaj, navíc jednodenní "validační" turnaj na projektu s DL tasků 10,5 dne považuji za úplný nesmysl, je to pouze o tom, kdo si více nasyslil a předpočítal a má kliku na spolupočtáře.
Ovšem nic proti přihlášení týmu, výkon máme stabilně druhý nejvyšší za Poláky, musel by to udělat Forest. I když v době trvání turnaje budeme všichni počítat PG a nikdo Asteroidy, skončíme druzí, je to úplně jedno.

OT: stejný velmi vlažný vztah mám ke všem týmovým výzvám, zejména pak na projektech, které potřebují validaci druhým počtářem - s výjimkou specifického Pentathlonu.

[eisler jiri]

já neznám proč se dělají turnaje překrývajíce se se. asteroids je sice naše, ale blbost vyhlásit f termínech kolidujících s jinými . to je jako vyhlásit Olympijské hry a MS světa neb okresní přebor f Kardašově řečici naráz tak zůstanu na zavedéném
pokud se neudělá termínová listina turnajů tak je to cochcárna
ale nic proti tomu život bude pestřejší

[Michal Kinďura]

S projektem to sice přímo nesouvisí, ale na ZOOM je teď (online už asi jen týden) dokument o asteroidech, drahých kovech...

Hlavně od třicáté minuty přímo o drahých kovech na asteroidech

Kód: Vybrat vše

Odhalený vesmír II (2) 

Vesmír je plný drahocenných pokladů. Po dopadu asteroidů na Zemi vznikala naleziště vzácných kovů nebo diamantů. Ve vesmíru se vyskytuje i helium 3, které se může stát na cenným zdrojem energie. Lidstvo však musí najít způsoby, kterými by bylo možné tyto poklady z vesmíru získat... Americký dokument (2011)

http://play.iprima.cz/zoom/398730/all

[nenym]

Kyongu, dotaz:
Max tasks per day se vztahuje na jedno jádro CPU nebo na celý stroj?
Proč se ptám:
Pokud těch 500 je na celý stroj, tak po zavedení 64bit SSE3 aplikace mohou mít přetaktované šestijádrové i7 teoreticky hlad. Moje čtyřjádrová i7 nepřetaktovaná (pouze trubo režimu na 4 GHz) dává task za cca 1120s, což jest 77 tasků za den na jádro. Při HT a vypnutých grafárnách běží jeden task dokonce 2180s, což jest 39,6 tasku za den na jádro. Na HT šestijádru by to mohlo být tedy 475 tasků bez přetaktu. Sem tam nějaký download horror či drobný přetakt a je hlad. Asi bych to teď neřešil, protože k takovému CPU je obvykle výkonná GPU, která si kus výkonu vezme a 500 je prakticky s dostatečnou rezervou. S příchodem GPU aplikace s tím ale něco budeš muset udělat (tedy alespoň doufám, že bude výkonnější, než SSE3, i když DP na nV není žádný zázrak).

[eisler jiri]

no tak nenym nemusíš být dopředu taký hamoun, můžeš vedle počítat něco jiného (třeba ovečky). hlavně už aby to bylo. zatím natahuje jen 101.10

[Michal Kinďura]

Není lepší nastavit jenom parametr maximálního počtu současně zpracovávaných tasků?

[Kyong]

Kyongu, dotaz:
Max tasks per day se vztahuje na jedno jádro CPU nebo na celý stroj?
Proč se ptám:
Pokud těch 500 je na celý stroj, tak po zavedení 64bit SSE3 aplikace mohou mít přetaktované šestijádrové i7 teoreticky hlad. Moje čtyřjádrová i7 nepřetaktovaná (pouze trubo režimu na 4 GHz) dává task za cca 1120s, což jest 77 tasků za den na jádro. Při HT a vypnutých grafárnách běží jeden task dokonce 2180s, což jest 39,6 tasku za den na jádro. Na HT šestijádru by to mohlo být tedy 475 tasků bez přetaktu. Sem tam nějaký download horror či drobný přetakt a je hlad. Asi bych to teď neřešil, protože k takovému CPU je obvykle výkonná GPU, která si kus výkonu vezme a 500 je prakticky s dostatečnou rezervou. S příchodem GPU aplikace s tím ale něco budeš muset udělat (tedy alespoň doufám, že bude výkonnější, než SSE3, i když DP na nV není žádný zázrak).

Je to na jedno jádro, těch 500 se násobí počtem jader a ještě se přičítá koeficient * počet GPU. Jelikož koeficient pro grafiku nemám definovaný, tak by to mělo přičítat pouze počet GPU.

Jinak teoreticky bych večer ty SSE3 optimalizace vypustil, ale ještě stále testuji, jestli to počítá a jestli to na všech systémech počítá správně (v normě). Debian 32 i 64 bit už prošel, Win 7 64bit a Win XP 32 i 64 taky. Vista by teoreticky fungovat měla taky, ale Win 8 už občas dělá problémy, takže ještě to rozhodně otestuji na tom. U linuxu by měl stačit ten test na Debianu, na OpenSuse jsem testoval jenom na zkrácené jednotce a ta prošla.

[Michal Kinďura]

Tak už ten 64 bit Linux konečně vypusť, chodím tady už od včerejška jak mlsný vlk okolo a čekám, kdy se to objeví venku

[Kyong]

Já jsem zvyklý vypustit vždy vše najednou. Ale ještě musím upozornit na jednu věc, jakmile nějaký nový pc připojíte projektu, tak to ze začátku bude náhodně stahovat klasickou aplikaci i SSE optimalizaci. Je to kvůli tomu, že scheduler, pokud se jedná o stejnou architekturu, tak nevěří optimalizacím (nebo spíše vývojáři BOINC serveru), takže scheduler pošle párkrát obojí, aby vyzkoušel, jak rychle která aplikace počítá, a pak podle toho bude už posílat konkrétní verzi, čili by to měla být SSE3 optimalizace v tomto případě. V nastavení XML pro detekci CPU a GPU jde sice nastavit koeficient pro preferování konkrétní verze, ale bohužel to nemá vliv na základní a i kdyby mělo, tak stejně to pošle různé verze a podle FLOPS to pak vynásobí ještě tím koeficientem. Takže to je takové krátké vysvětlení, řešil jsem to právě včera na developer mailingu a vývojáři to bohužel udělali tak, jak to udělali. Jediná možnost, aby to okamžitě posílalo verzi podle detekce instrukcí je napsat si vlastní scheduler, což je ovšem pak zase problém při upgradu serveru, protože po změně některých částí serveru by pak zase nefungoval a musel by se znova přepisovat.
Takže zkrádně, nelekejte se, pokud to bude posílat náhodně aplikace oboje a rozhodně je ani nerušte, protože dokud si pár těch normální nenapočítá, aby zjistil, kterou aplikaci tomu stroji poslat, tak je bude posílat náhodně stále.

[zdenek]

Takže to je takové krátké vysvětlení, řešil jsem to právě včera na developer mailingu a vývojáři to bohužel udělali tak, jak to udělali. Jediná možnost, aby to okamžitě posílalo verzi podle detekce instrukcí je napsat si vlastní scheduler, což je ovšem pak zase problém při upgradu serveru, protože po změně některých částí serveru by pak zase nefungoval a musel by se znova přepisovat.

Pořád říkám, že by je patřilo za tu serverovou stranu boincu postřílet.

[Kyong]

A hlavně za to info na wikipedii, kde část věcí nefunguje, protože je zastaralá a dost tam ani není.

[nenym]

Takže zkráceně, nelekejte se, pokud to bude posílat náhodně aplikace oboje a rozhodně je ani nerušte, protože dokud si pár těch normální nenapočítá, aby zjistil, kterou aplikaci tomu stroji poslat, tak je bude posílat náhodně stále.

Lze to obejít snadno na straně uživatele pomocí app_info a sekce download na serveru.
Jinak velká 1* za odvedenou práci pro Kyonga i Zdenka.

[zdenek]

A také jednu 1* pro nenyma za fantastické testování. Už si ani nepamatuju na čem všem to zkoušel.

[Michal Kinďura]

1*

[eisler jiri]

1** pro cecky