PG challenge
Napsal: pát 17 čer, 2011 13:18
Turnaje Prime Grid jsou 1 až 13 denní, od roku 2015 počítají se jeden až tři podprojekty v rámci jednoho turnaje. Některé lze počítat pouze na CPU, jiné i na GPU.
Započítávají se pouze ty jednotky turnajových aplikací, které byly nataženy po začátku turnaje a odevzdány před koncem. Kredit z jednotlivých podprojektů v rámci jednoho turnaje se sčítá dohromady. Jednotky, které neprojdou následnou validací, jsou od výsledného skóre odečteny, konečný výsledek je tedy znám až po skončení tzv. cleaning phase.
Příprava strojů před turnajem:
Sieve podprojekty – natáhnout před turnajem alespoň jednu jednotku kvůli obludným Sieve files (některé podprojekty jsou dataless, tedy bez sieve file). Jednotku lze po natažení zrušit či dopočítat (kvůli ověření času výpočtu) podle libosti.
LLR + GFN podprojekty – jsou to drtiče CPU. Vyčistit počítač, vyfoukat prach z chladičů, vyhnat pavouky, prověřit/promazat ventilátory. Poté ověřit na několika jednotkách stabilní přetakt počítače a průběžně kontrolovat teplotu CPU. Při paralelním běhu 4 tasků je vhodné počítat pesimisticky s navýšením doby o cca 50 % proti výpočtu sólo single tasku (co task navíc přibližně + 15 % aktuálního času, tedy pokud je doba jednoho tasku 10 hodin: 1=10, 2=11.5, 3=13.2, 4=15), záleží ta konkrétní konfiguraci - některé dosahují lepších časů. Výpočty na integrované GPU rovněž dobu úspěšně prodlužují.
Pro Sieve podprojekty je výhodné zapnutí HT, pro LLR + GFN podprojekty je naopak HT kontraproduktivní.
Příprava Boinc před turnajem:
V zásadě zavčasu vyčistit zásobu PG libovolných jednotek (kdo počítá SoB LLR a cpuGFN , tak si musí dát pozor na začátek turnaje sám, oznámení na našem fóru bývá později, než je doba výpočtu těchto oblud). Rozpočítané dopočítat, ty co se nestihnou do začátku turnaje zrušit.
Proč? Protože při pozastavené libovolné jednotce daného projektu se další nenatahují. Vůbec nehraje roli, že je pozastavená například CPU LLR jednotka a chcete natahovat GPU Sieve jednotku, o práci si BM prostě neřekne.
Existuje samozřejmě micromanagement jednotek, kterým lze uchovat rozpočítané jednotky jiného podprojektu a přitom natáhnout a během turnaje počítat pouze turnajové jednotky, ale kdo to umí, ten žádný návod nepotřebuje a toto ani nečte (návod doplněn).
Nastavit v preferencích na PG pouze turnajové podprojekty, povolit CPU a příslušné druhy GPU (nVidia/ATI) jak pro podprojekty, tak pro daný profil, tedy 2x. Nepovolovat pro daný profil počítače GPU, které ve stroji nejsou, některé verze Boinc core jsou z toho zmatené a nežádají si o další práci.
Vynulovat dluhy (není nezbytně nutné, ale doporučeníhodné) - v core verze 7+ se dluhy nepoužívají.
Strategie:
A. Sedím u stroje a PG je pozastavený či má zakázaný příjem práce, buffer PG je prázdný. Stroj počítá něco jiného, pokud možno s checkpointy
Je minuta před začátkem turnaje. POZOR na webu PG musí být ten správný čas, nespoléhat na odpočítávadlo, to jede podle času vašeho stroje.
- vyčkat na správný čas T,
- obnovit/povolit příjem práce PG,
- pozastavit ostatní projekty,
- nastavit zásobu na odpovídající dobu (nejméně 24 hodin),
- chroustat,
- v cc_config.xml zavčasu nastavit featuru <report_results_immediately>1</report_results_immediately>, stačí několik hodin před koncem turnaje.
Na konci turnaje vše vrátit do původních nastavení, nenačaté jednotky zrušit či dopočítat dle chuti a nálady. Na turnaj nemají vliv.
B. Nesedím u stroje a neumím zacházet s boinccmd a plánovačem úloh (Wirouz) či cronem (Linuxy)
Než od stroje definitivně odejdu, je nutné provést
- nastavit v preferencích na PG pouze turnajové podprojekty,
- pozastavit všechny ostatní projekty, i exoty bez práce, náhoda je blbec,
- nastavit buffer na 0,01, tím bude dosaženo, že zpoždění proti začátku turnaje bude nejvýše délka výpočtu jedné jednotky,
- v cc_config.xml nastavit featuru <report_results_immediately>1</report_results_immediately>,
- odejít.
C. Nesedím u stroje a umím zacházet s boinccmd a plánovačem úloh (Wirouz) či cronem (Linuxy)
V tom případě žádný návod pravděpodobně nepotřebuji, nastavím vše potřebné v libovolném předstihu a jdu tam, kam potřebuji. Pro jistotu čas na spuštění potřebného baťáku/scriptu nastavím na T + 2 minuty.
Pouze zhruba:
- dopředu u stroje: cc_config, preference PG, buffer,
- v plánovači: na čas T+2 min pozastavení ostatních projektů, povolení PG; případně na konci turnaje provést inverzi nastavení.
Doporučení: baťák/script pro plánovač odzkoušet, překlepi jsou potfora, moje vlastní zkušenost. Nastavit na období T až T+1 hodina aktualizaci projektu PG (update) v intervalu 2 minuty. Po zbytek turnaje stačí interval doby výpočtu jedné jednotky. Lze totiž předpokládat přetížení serveru a následný timeout klienta. - nyní již zbytečné, servery PG zvládají téměř vše.
Pozn: návod na cc_config.xml.
Micromanagement rozpočítaných jednotek nevhodného podprojektu:
- pozastavit jednotky nevhodného podprojektu,
- pomocí <ncpus> v cc_config.xml nastavit 2n či 3n jader + načíst konfigurační soubory,
- nastavit potřebnou zásobu,
- obnovit jednotky nevhodného podprojektu + update projektu - případně několikrát zopakovat se zvedáním zásoby,
- pozastavit jednotky nevhodného podprojektu,
- vrátit počet jader na správnou hodnotu + načíst konfigurační soubory, alternativa: nastavit skutečný počet jader jako % využití POČTU CPU v BM, vhodné pro opakované natahování jednotek bez nutnosti pořád rýpat do cc_config.
Pozn: V posledním kroku nelze použít hodnotu <ncpus>-1</ncpus> v cc_config.xml bez restartu Boinc core. Pokud nechcete restartovat (asi ne během turnaje), tak je nutné zadat skutečný počet jader a -1 zadat až před restartem core.
Management (rozpočítaných) dlouhých jednotek v časové tísni. Připomínám přibližný vztah z úvodu - co task navíc přibližně + 15 % aktuálního času, který platí i naopak.
1. Jednoduchý
Pozastavit potřebný počet jednotek, aby se dopočítalo aspoň něco
2. Micromanagement (na dvoujádře) - 4 jednotky se nestíhají dopočítat, při dvou jednotkách zbude do konce turnaje na přibližně polovinu délky jednotky: Natáhnout 3 jednotky, první pozastavit v půlce, držet pozastavenou do dopočítání druhé (se kterou běží třetí) a pak dopočítat společně první a třetí. Na 4 jádře obdobně, navíc se dá kouzlit s počtem jader - 3 a v totální nouzi 2.
Započítávají se pouze ty jednotky turnajových aplikací, které byly nataženy po začátku turnaje a odevzdány před koncem. Kredit z jednotlivých podprojektů v rámci jednoho turnaje se sčítá dohromady. Jednotky, které neprojdou následnou validací, jsou od výsledného skóre odečteny, konečný výsledek je tedy znám až po skončení tzv. cleaning phase.
Příprava strojů před turnajem:
Sieve podprojekty – natáhnout před turnajem alespoň jednu jednotku kvůli obludným Sieve files (některé podprojekty jsou dataless, tedy bez sieve file). Jednotku lze po natažení zrušit či dopočítat (kvůli ověření času výpočtu) podle libosti.
LLR + GFN podprojekty – jsou to drtiče CPU. Vyčistit počítač, vyfoukat prach z chladičů, vyhnat pavouky, prověřit/promazat ventilátory. Poté ověřit na několika jednotkách stabilní přetakt počítače a průběžně kontrolovat teplotu CPU. Při paralelním běhu 4 tasků je vhodné počítat pesimisticky s navýšením doby o cca 50 % proti výpočtu sólo single tasku (co task navíc přibližně + 15 % aktuálního času, tedy pokud je doba jednoho tasku 10 hodin: 1=10, 2=11.5, 3=13.2, 4=15), záleží ta konkrétní konfiguraci - některé dosahují lepších časů. Výpočty na integrované GPU rovněž dobu úspěšně prodlužují.
Pro Sieve podprojekty je výhodné zapnutí HT, pro LLR + GFN podprojekty je naopak HT kontraproduktivní.
Příprava Boinc před turnajem:
V zásadě zavčasu vyčistit zásobu PG libovolných jednotek (kdo počítá SoB LLR a cpuGFN , tak si musí dát pozor na začátek turnaje sám, oznámení na našem fóru bývá později, než je doba výpočtu těchto oblud). Rozpočítané dopočítat, ty co se nestihnou do začátku turnaje zrušit.
Proč? Protože při pozastavené libovolné jednotce daného projektu se další nenatahují. Vůbec nehraje roli, že je pozastavená například CPU LLR jednotka a chcete natahovat GPU Sieve jednotku, o práci si BM prostě neřekne.
Existuje samozřejmě micromanagement jednotek, kterým lze uchovat rozpočítané jednotky jiného podprojektu a přitom natáhnout a během turnaje počítat pouze turnajové jednotky, ale kdo to umí, ten žádný návod nepotřebuje a toto ani nečte (návod doplněn).
Nastavit v preferencích na PG pouze turnajové podprojekty, povolit CPU a příslušné druhy GPU (nVidia/ATI) jak pro podprojekty, tak pro daný profil, tedy 2x. Nepovolovat pro daný profil počítače GPU, které ve stroji nejsou, některé verze Boinc core jsou z toho zmatené a nežádají si o další práci.
Vynulovat dluhy (není nezbytně nutné, ale doporučeníhodné) - v core verze 7+ se dluhy nepoužívají.
Strategie:
A. Sedím u stroje a PG je pozastavený či má zakázaný příjem práce, buffer PG je prázdný. Stroj počítá něco jiného, pokud možno s checkpointy
Je minuta před začátkem turnaje. POZOR na webu PG musí být ten správný čas, nespoléhat na odpočítávadlo, to jede podle času vašeho stroje.
- vyčkat na správný čas T,
- obnovit/povolit příjem práce PG,
- pozastavit ostatní projekty,
- nastavit zásobu na odpovídající dobu (nejméně 24 hodin),
- chroustat,
- v cc_config.xml zavčasu nastavit featuru <report_results_immediately>1</report_results_immediately>, stačí několik hodin před koncem turnaje.
Na konci turnaje vše vrátit do původních nastavení, nenačaté jednotky zrušit či dopočítat dle chuti a nálady. Na turnaj nemají vliv.
B. Nesedím u stroje a neumím zacházet s boinccmd a plánovačem úloh (Wirouz) či cronem (Linuxy)
Než od stroje definitivně odejdu, je nutné provést
- nastavit v preferencích na PG pouze turnajové podprojekty,
- pozastavit všechny ostatní projekty, i exoty bez práce, náhoda je blbec,
- nastavit buffer na 0,01, tím bude dosaženo, že zpoždění proti začátku turnaje bude nejvýše délka výpočtu jedné jednotky,
- v cc_config.xml nastavit featuru <report_results_immediately>1</report_results_immediately>,
- odejít.
C. Nesedím u stroje a umím zacházet s boinccmd a plánovačem úloh (Wirouz) či cronem (Linuxy)
V tom případě žádný návod pravděpodobně nepotřebuji, nastavím vše potřebné v libovolném předstihu a jdu tam, kam potřebuji. Pro jistotu čas na spuštění potřebného baťáku/scriptu nastavím na T + 2 minuty.
Pouze zhruba:
- dopředu u stroje: cc_config, preference PG, buffer,
- v plánovači: na čas T+2 min pozastavení ostatních projektů, povolení PG; případně na konci turnaje provést inverzi nastavení.
Doporučení: baťák/script pro plánovač odzkoušet, překlepi jsou potfora, moje vlastní zkušenost. Nastavit na období T až T+1 hodina aktualizaci projektu PG (update) v intervalu 2 minuty. Po zbytek turnaje stačí interval doby výpočtu jedné jednotky. Lze totiž předpokládat přetížení serveru a následný timeout klienta. - nyní již zbytečné, servery PG zvládají téměř vše.
Pozn: návod na cc_config.xml.
Micromanagement rozpočítaných jednotek nevhodného podprojektu:
- pozastavit jednotky nevhodného podprojektu,
- pomocí <ncpus> v cc_config.xml nastavit 2n či 3n jader + načíst konfigurační soubory,
- nastavit potřebnou zásobu,
- obnovit jednotky nevhodného podprojektu + update projektu - případně několikrát zopakovat se zvedáním zásoby,
- pozastavit jednotky nevhodného podprojektu,
- vrátit počet jader na správnou hodnotu + načíst konfigurační soubory, alternativa: nastavit skutečný počet jader jako % využití POČTU CPU v BM, vhodné pro opakované natahování jednotek bez nutnosti pořád rýpat do cc_config.
Pozn: V posledním kroku nelze použít hodnotu <ncpus>-1</ncpus> v cc_config.xml bez restartu Boinc core. Pokud nechcete restartovat (asi ne během turnaje), tak je nutné zadat skutečný počet jader a -1 zadat až před restartem core.
Management (rozpočítaných) dlouhých jednotek v časové tísni. Připomínám přibližný vztah z úvodu - co task navíc přibližně + 15 % aktuálního času, který platí i naopak.
1. Jednoduchý
Pozastavit potřebný počet jednotek, aby se dopočítalo aspoň něco
2. Micromanagement (na dvoujádře) - 4 jednotky se nestíhají dopočítat, při dvou jednotkách zbude do konce turnaje na přibližně polovinu délky jednotky: Natáhnout 3 jednotky, první pozastavit v půlce, držet pozastavenou do dopočítání druhé (se kterou běží třetí) a pak dopočítat společně první a třetí. Na 4 jádře obdobně, navíc se dá kouzlit s počtem jader - 3 a v totální nouzi 2.