Forum boinc.cz

Zdravicko.
Pred casem jsme se bavili o (ne)moznosti nastavit zasobu pro jednotlive projekty.
Osobne bych si predstavoval nasledujici nastaveni. LHC zasoba treba 6 dni, Einstein 0.1 dne. Duvod je jasny. Preferuju LHC a to ma obcas vypadky v dodavani jednotek, takze je potreba mit vetsi zasobu. Pokud jsou jednotky, tak bych chtel, aby se maximalne pocitalo LHC. Kdyz dojde, tak at si jede Einstein, ale at si nedela moc velkou zasobu a jakmile LHC pusti dalsi praci, tak at zase jede LHC.
Jde to udelat napriklad rucnim pridanim projektu Einstein pri vypadku dat z LHC a zrusenim E@H kdyz data jsou. Ale to je jednak zbytecna prace a jednak kdyz si clovek nevsimne, tak muze pocitac "jet na prazdno".
Napadlo me, jestli by treba nezafungovalo, ze by u E@H byl profile s kratkou zasobou a u LHC s dlouhou. Ale obavam se, ze by to nefungovalo, protoze v client_state.xml je host_venue jenom jednou. Navic 3 profile jsou hodne malo. Zkusil jsem to nastavit, ale vysledek budu znat az za par dni a to jen v pripade, ze LHC nedojde prace.
Pokud ma nekdo vyzkouseny postup, tak ho sem hodte. Zalozni projekt se urcite hodi hodne lidem. Obzvlast na pocitacich, kam se clovek tak casto nedostane.
Libor

Jistou teorii mám, neměl sem příležitost v praxi ověřit.
Tenkrát jak SETI mělo krizi, nahodil sem na všech compech jako zálohu Einstein. Když jsme se přes krizi překlepali, chtěl sem zase počítat hlavně SETI, ale Einsteina si nechat v záloze pro případ nouze. Zůstal sem všude připojenej, ale nastavil sem Einsteinu naprosto minimální sdílení prostředků (Resource share v preferencích projektu). Ze sto procent výpočetního času zůstalo SETI 99, na Einstein zbylo jedno. Obrazně se dá říci, že 99 dní se počítá SETI, jeden den Einstein. Takhle by to vypadalo v případě kdy všechno chodí. Čistě teoreticky si myslím, že kdyby SETI z nějakýho důvodu kixlo a nebyla práce, BOINC by si mohl říct o práci u Einsteina, s tím že by dělal na dluh. Ale tenkrát od tý krize u SETI žádnej dlouhej výpadek nebyl, takže netuším jestli by to v praxi zafungovalo. Určitě by nebyl velkej problém si to vyzkoušet. LHC je věčně bez jednotek, tak zkušebně dát LHC velkej resource share, druhýmu projektu jen nezbytný minimum a počkat až bude LHC bez práce a sledovat jak se to zachová.
I kdyby to nezafungovalo a BOINC si u druhýho projektu o práci neřekl, nabízí se poměrně jednoduchý řešení. Změním poměry u resource share tak, aby z vedlejšího byl projekt hlavní a compy si při kontaktu se schedulerem začnou říkat o práci u něj. Tohle asi má svý háčky, sem si jich vědomej. Pvní varianta, kdy by si při nedostatku práce u jednoho projektu začal o ní říkat u druhýho by byla optimální.

Počítám LHC, pokud nemá jednotky tak jedu CPDN, řešení je jednoduché, na LHC nastavím 99.9999% prioritu a CPDN má zbytek, během doby kdy má LHC jednotky, tak se CPDN ke slovu nedostane, pokud dojdou, tak se CPDN pustí.
dejv

dejvidek píše:Počítám LHC, pokud nemá jednotky tak jedu CPDN, řešení je jednoduché, na LHC nastavím 99.9999% prioritu a CPDN má zbytek, během doby kdy má LHC jednotky, tak se CPDN ke slovu nedostane, pokud dojdou, tak se CPDN pustí.
dejv

Mam to nastavene na 10:90. Nastavil bych to i na vic, jenze pak muze nastat problem s deadline. Kdyz nahodou ma praci porad, tak se Einstein skoro nedostane k lizu a jednotka propadne. Deadline je bohuzel u vsech projektu.
Libor

vejpuste píše:Mam to nastavene na 10:90. Nastavil bych to i na vic, jenze pak muze nastat problem s deadline. Kdyz nahodou ma praci porad, tak se Einstein skoro nedostane k lizu a jednotka propadne. Deadline je bohuzel u vsech projektu.

Nepropadne. Jakmile se blizi deadline nejake jednotky, BOINC klient ji nastartuje bez ohledu na nastavene procento sdileni. Zalezi ale hodne na verzi klienta - kazda verze se chova trosicku jinak: to zachazeni se sdilenim prostredku vice projektu, deadlines, procentem pripojeni, atd - to je oblast klienta, ktera je nejproblematictejsi a neustale se doladuje. Poslednich par verzi ale u me funguje celkem bez problemu.

2vejpuste: Proto mám jako druhý projekt CPDN, kde deadline neřeším ani na mém muzeiním compu.
dejv

Zasoba jednotek je v General preferences, ktere se aplikuji "General" a nejsou specificke pro danou masinu ci projekt. To samosebou pouzit nelze.
Snadnou pomoci je resource share.
Ohledne problemu deadline to naznacil trux - kdyz se neco blizi deadline, BOINC prejde z resource-share schematu (round-robin) na earlier-deadline first, na coz sice nekteri lide nadavaji, ale vetsinou z duvodu, ze si to neumeji nastavit share s ohledem na deadline jednotek jednotlivych projektu.

Pro fajnsmekry bych doporucil se podivat, sledovat a mozna ladit Long Term Debt u jednotlivych projektu.
Co se typicky deje je, ze ma nekdo dva projekty bez dalsiho nastaveni (share je 100:100 resp. 50:50). Nektery projekt nema praci, takze mu vznika dluh. Jakmile se zase rozjede, nejedou vlastne 50:50 (byt to tak mam user nastavene), protoze se to schematu zapoji Long Term Debt.

Myslim, ze schema General: work for x days, Resource share a Long Term Debt jsou dobre. Bordel v tom dela benchmark a projekty, ktere najedou maji kratky deadline.
K lepsi 'kalibraci' lze pouzit Result duration correction factor, protoze je specificky pro danou masinu (a BOINC magor by s nim mel pracovat) a pripadne Average turnaround time na strane serveru.

Zdá se, že někdy je zásoba jedntek dobrá, od rána se mi neodesílají zpracované WU na S@H, je to jen můj problém, nebo to nejde globálně??? na stránkách S@H není ani čárka a podle mně už by mohli být na druhé straně velké louže vzhůru,ne???

O těchto problémech jsem psal i zde na fóru už včera:
http://boinc.cz/forum/viewtopic.php?t=761&highlight=
Na odstranění se pracuje.

Jen tak na doplnění, jednotky se stáhnout stále ještě dají poměrně snadno. Horší je to z jejich odesláním, ale i to po pár domluvách zatím prochází.

dejvidek píše:2vejpuste: Proto mám jako druhý projekt CPDN, kde deadline neřeším ani na mém muzeiním compu.
dejv

Jenom pro upresneni.
Neresis ho proto, ze dostavas kredit prubezne a nevadi, ze jednotku nedokoncis nebo proto, ze je deadline tak velky, ze to stihnes dopocitat vzdy?
U CDPN mi vadi hodne velka rozlezlost po disku a v pameti. Starsi stroje vetsinou nemaji nadupane ani jedno.
Libor

vejpuste píše:U CDPN mi vadi hodne velka rozlezlost po disku a v pameti. Starsi stroje vetsinou nemaji nadupane ani jedno.

Dost projektu reze podobne nebo vyssi naroky na pamet nez CPDN, takze to neni moc silny argument. Ano, naroky na disk jsou vetsi...jestli ale nekdo nema 1GB mista, tak je to pekna plecka... Z tohole hlediska je nejlepsi Einsteina - staci malo pameti, malo mista na disku.

vejpuste píše:Neresis ho proto, ze dostavas kredit prubezne a nevadi, ze jednotku nedokoncis nebo proto, ze je deadline tak velky, ze to stihnes dopocitat vzdy?
U CDPN mi vadi hodne velka rozlezlost po disku a v pameti. Starsi stroje vetsinou nemaji nadupane ani jedno.
Libor

Jednotu i na mém krámu bez problémů dokončím a to že kredit dostávám průběžně bez ohledu na to kdy mám možnost aby mi BOINC běžel (resp. kdy nejsou data u LHC) mi naprosto vyhovuje. Zatím sem celý model nedopočítal, důvodem byl ze začátku přetatovaný procesor, někdy to, že jsem zkoušel nové verze, či moje blbost (smazání zálohy).
Co se týče paměti, tak mi to žere 40MB, což je jen o 10MB než nenažraný FireFox . A to mám jen 384MB paměti, co se týče velikosti na disku, ano jsou počítače kde to může být problém, drtivá většina lidí má disky větší než je 40GB a tam se 1GB dá uvolnit bez problémů (snížení swapu, vypnutí režimu spánku, obnovení systému, smazání či zmenšení cache u browseru, atd.)
dejv

Ono u CPDN někdy nejde jen o 1GB, ale při počítání 2 modelů naráz až 2GB a při pravidelné záloze, která je u tohoto projektu téměř nutností při snaze kompletního dokončení modelu se tentoprostor ještě násobí.

U ostatních projektů jde jen o pár MB a zálohovat prakticky není potřeba, pokud neprovádíte nějaké experimenty

forest píše:Ono u CPDN nìkdy nejde jen o 1GB, ale pøi poèítání 2 modelù naráz až 2GB a pøi pravidelné záloze, která je u tohoto projektu témìø nutností pøi snaze kompletního dokonèení modelu se tentoprostor ještì násobí.

Nenasoby, kdyz to zapakujes, coz vzdy doporucuji nejen kvuli mistu. Jinak souhlas, CPDN zere nejvic mista na disku - asi tolik jako jedna dnesni hra nebo pulka prekopirovane DVD filmu nebo scanny do jedne obrazkove publikace.

No foreste řekl si nám to asi už po desáté, každý z nás ví kolik CPDN žere a jaké jsou (ne) výhody. Chápu ale, že pokud se najde střevo co si koupí Presscota (tedy s HT), k tomu 512MB paměti, nahodí na to XPéčka a má to všechno na 40GB disku, tak ho každej MB zajímá. Rozumnej člověk má minimálně 100GB disk a 5% s kapacity ho nezabije, 5% se dá ušetřit (už sem to psal jak). Zabalením se dá záloha smrsknout na 75% velikosti (standartní komprese u RARu). Já si zálohy kopíruju na DVD-RAM médium, takže mě místo nějak netrápí. Tam se vejdou bez problémů 3 modely.
dejv