Dobrý den všem,
mám drobný dotaz. Jedu SC model a u jednohu compu se mi vysypal HDD. Podařilo se mi vše obnovit s vyjímkou client state.xml. Mám nějakou zálohu, ale je měsíc stará. Nicméně je to záloha od aktuálního výpočtu. Teď to hlavní = před výpadkem byl SC model u 40%. Záloha je při 10%. Model mi počítá dál = data nebyla poškozena, ale neodeslal se .zip druhé fáze SC. A jelikož client state je nyní z dřívější zálohy tk už ho neodešle.
Můj dotaz je´- lze nějak rekonstruovat záznam v client state tak aby se .zip odeslal?
Dík Zdespi
client_state.xml poškozen - možnost opravy?
Moderátoři: zdespi, Moderátoři
-
forest
- Příspěvky: 2573
- Registrován: pát srp 27, 2004 12:50 pm
- Bydliště: Újezd u Brna 31 let
- Kontaktovat uživatele:
Pokud vím, tak bohužel to nejde, jediný způsob je vždy obnova ze zálohy, či obnova díky souboru client_state_prev.xml, který lze ale použít jen před spuštěním té poškozené instalace, jelikož pak se přepíše tím poškozeným client_state.xml a je v nenávratnu.
Začínat počítat zase od 10% je nesmysl, jelikož 10% není nijak moc práce s ohledem na to, že by jsi až do těch 40% nedostal za svou práci žádný Credit. Doporučuji tedy stáhnout si nový model a ten v průběhu výpočtu častěji zálohovat.
Začínat počítat zase od 10% je nesmysl, jelikož 10% není nijak moc práce s ohledem na to, že by jsi až do těch 40% nedostal za svou práci žádný Credit. Doporučuji tedy stáhnout si nový model a ten v průběhu výpočtu častěji zálohovat.
Toto je původní fórum Czech National Teamu, které se v listopadu 2006 přesunulo na tuto novou adresu.
Moc s forestem nesouhlasim.
Dost zalezi na tom, co je v client_state.xml poskozeno.
Jako prvni bych zazalohoval to co zbylo; kdyz se v tom bude rypat, je lepsi to dat do zalohy.
Pokud mas zapojeny pouze CPDN a od zalohy se nezmenil pocet jednotek (aplikace v tomto pripade asi sotva), tak s velkou pravdepodobnosti lze restaurovat client_state.xml ze stare zalohy a pripadne trochu poupravit. Muze to vygenerovat novou masinu kvuli nesouhlasejici sekvenci RPC se serverem, ale nova masina se da spojit s puvodni. To je trebas pouze kosmeticky problem.
I pripadne nesrovanolosti s tim, ve kterem slotu dany model pojede jde snadno doladit.
Jestli se (ne)vygenereoval a (ne)uploadoval prubezny vysledek nebo ne lze poznal z historie vypisu stdoutdae.txt
Proste v BOINCu je hodne voditek, jak to restaurovat, reps. co aktualizovat v client_state.xml od posledni zalohy.
Jelikoz CPDN prijme vysledek modelu znovu bez ohledu na predchozi stav (error), klidne muzes hodit stary client_state.xml ze zalohy, prpadne si v nem rucne si v nem pro jistotu vypnout network, dat no new work a podobne drobnosti a zkusit to rozjet.
Myslim, ze by to stalo za pokus zachranit tech 30% vypoctu.
Pokud ale chces mit jistotu vyvarovat se tomu, ze se vypoctech nic nepodelalo (nezlobyl ten HD uz trochu predtim?), tak je lepsi zacit pocitat novy model.
Dost zalezi na tom, co je v client_state.xml poskozeno.
Jako prvni bych zazalohoval to co zbylo; kdyz se v tom bude rypat, je lepsi to dat do zalohy.
Pokud mas zapojeny pouze CPDN a od zalohy se nezmenil pocet jednotek (aplikace v tomto pripade asi sotva), tak s velkou pravdepodobnosti lze restaurovat client_state.xml ze stare zalohy a pripadne trochu poupravit. Muze to vygenerovat novou masinu kvuli nesouhlasejici sekvenci RPC se serverem, ale nova masina se da spojit s puvodni. To je trebas pouze kosmeticky problem.
I pripadne nesrovanolosti s tim, ve kterem slotu dany model pojede jde snadno doladit.
Jestli se (ne)vygenereoval a (ne)uploadoval prubezny vysledek nebo ne lze poznal z historie vypisu stdoutdae.txt
Proste v BOINCu je hodne voditek, jak to restaurovat, reps. co aktualizovat v client_state.xml od posledni zalohy.
Jelikoz CPDN prijme vysledek modelu znovu bez ohledu na predchozi stav (error), klidne muzes hodit stary client_state.xml ze zalohy, prpadne si v nem rucne si v nem pro jistotu vypnout network, dat no new work a podobne drobnosti a zkusit to rozjet.
Myslim, ze by to stalo za pokus zachranit tech 30% vypoctu.
Pokud ale chces mit jistotu vyvarovat se tomu, ze se vypoctech nic nepodelalo (nezlobyl ten HD uz trochu predtim?), tak je lepsi zacit pocitat novy model.
No dostal sem se sem teprve teď.
Client_state byl komplet prázdný. Jako kdyby se najel boinc poprve - jen host info atd.
Kdyz sem prihral state file ze zalohy, tak se vypocet rozjel bez problemu od 40 % dal. I trickly odesilal. Problem je, ze mi zustal neodaslany ten .zip pro druhou fazi. Kdyby se dalo nejak do client state doplnit, ze ho ma odeslat, bylo by vse OK. Ale nevim jak spocitat MD5 hash pro ten soubor. Staci pro to nejakej MD5 checker nebo ma boinc neco sveho?
Myslim tohle:
<file_info>
<name>sulphur_ibyl_100855309_0_2.zip</name>
<nbytes>0.000000</nbytes>
<max_nbytes>10000000.000000</max_nbytes>
<generated_locally/>
<status>0</status>
<upload_when_present/>
<url>http://uploader1.atm.ox.ac.uk/cpdn_cgi/ ... ndler</url>
<signed_xml>
<name>sulphur_ibyl_100855309_0_2.zip</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>10000000</max_nbytes>
<url> http://uploader1.atm.ox.ac.uk/cpdn_cgi/ ... ad_handler </url>
</signed_xml>
<xml_signature>
ac72da1d4292ad57127bae98db3a79f9621fcfaeba490fc3b5122593071093f8
04d66314f4334830fc9a5de3a902bc92cc7cf96211072bf9bc2fd745deb50aa1
a9ad067a85fa8c871c8e26b739e62c2a107d2e3b356d76163bb1bcef2522a962
03db44dbca8f6a475febcadfe66e5ea6e34359162bbe04cf01385445dd193dde
Dik Zdenek
Client_state byl komplet prázdný. Jako kdyby se najel boinc poprve - jen host info atd.
Kdyz sem prihral state file ze zalohy, tak se vypocet rozjel bez problemu od 40 % dal. I trickly odesilal. Problem je, ze mi zustal neodaslany ten .zip pro druhou fazi. Kdyby se dalo nejak do client state doplnit, ze ho ma odeslat, bylo by vse OK. Ale nevim jak spocitat MD5 hash pro ten soubor. Staci pro to nejakej MD5 checker nebo ma boinc neco sveho?
Myslim tohle:
<file_info>
<name>sulphur_ibyl_100855309_0_2.zip</name>
<nbytes>0.000000</nbytes>
<max_nbytes>10000000.000000</max_nbytes>
<generated_locally/>
<status>0</status>
<upload_when_present/>
<url>http://uploader1.atm.ox.ac.uk/cpdn_cgi/ ... ndler</url>
<signed_xml>
<name>sulphur_ibyl_100855309_0_2.zip</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>10000000</max_nbytes>
<url> http://uploader1.atm.ox.ac.uk/cpdn_cgi/ ... ad_handler </url>
</signed_xml>
<xml_signature>
ac72da1d4292ad57127bae98db3a79f9621fcfaeba490fc3b5122593071093f8
04d66314f4334830fc9a5de3a902bc92cc7cf96211072bf9bc2fd745deb50aa1
a9ad067a85fa8c871c8e26b739e62c2a107d2e3b356d76163bb1bcef2522a962
03db44dbca8f6a475febcadfe66e5ea6e34359162bbe04cf01385445dd193dde
Dik Zdenek
Mno, problem je, ze v client_state.xml ma ted nastavenou nulovou delku (nbytes); (Nikda jsem nepochopil, proc BOINC stale obsahuje falesnou snahu o presnost ze udava velikost v bytech na 6 desetinnych mist 
)
Takze bych jako prvni zkusil doplnit skutecnou velikost souboru - takhle si BOINC mysli, ze soubor jeste nebyl vygenerovan.
Upload jede domu do Oxfordu (CPDN ma vice uploadovacich serveru); signature tam je, takze by to mohlo jit v pohode.
MD5, hmm
Na to je dost utilitek, pro Windows treba tahle
<file_info>
<name>sulphur_ibyl_100855309_0_2.zip</name>
<nbytes>0.000000</nbytes>
<max_nbytes>10000000.000000</max_nbytes>
<generated_locally/>
<status>0</status>
<upload_when_present/>
)Takze bych jako prvni zkusil doplnit skutecnou velikost souboru - takhle si BOINC mysli, ze soubor jeste nebyl vygenerovan.
Upload jede domu do Oxfordu (CPDN ma vice uploadovacich serveru); signature tam je, takze by to mohlo jit v pohode.
MD5, hmm
Na to je dost utilitek, pro Windows treba tahle<file_info>
<name>sulphur_ibyl_100855309_0_2.zip</name>
<nbytes>0.000000</nbytes>
<max_nbytes>10000000.000000</max_nbytes>
<generated_locally/>
<status>0</status>
<upload_when_present/>
Tomu rikas pocitani?reALTom píše:Jo, dobrá práce a chu� nìco vyøešit. Škoda jen, že se dají najít i takovéto poèítaèe. Nevím, proè to takoví lidé vùbec poèítají.
Klidne to muze byt spatnym nastavenim toho kompu - napriklad zakazany swap, malo mista na disku atp.
Je docela pravdepodobne, ze podobne masiny, ktere pouze zahazuji WUs, budou i na ostatnich projektech.
Akorat, ze takovym masinach oprava client_state.xml nepomuze...
Porušený soubor
Někdy koncem února jsem při přenosu z jednoho PC na druhé, přišel o nějaký soubor, možnost cesty zpět nebyla, zkusil jsem to spustit, ale nahlásilo to chybu, že chybí soubor a ukončilo se počítání. Myslel jsem, že připojením si snad něco stáhne, ale byl jsem naivka, navíc se mi těmi pitomými pokusy přepsaly i další soubory, zejména client_state.xml. Měl jsem hotovo asi 65 %, zde je odkaz ( http://climateapps2.oucs.ox.ac.uk/cpdnb ... id=1352716 )
Začal jsem tedy počítat novou jednotku. Už mám přes 40 %, tak jsem začal porovnávání abych zjistil , který soubor jsem ztratil. Byl to sulphur_xx99_999999999.zip z adresáře climatepredictin.net, podíval jsem se, co je v něm zazipované a vytvořil jsem si ho znovu. Ovšem nebylo to to pravé ořechové. Dalším bádáním jsem vymyslel nahradit soubory client_state.xml a sched_request_climateprediction.net.xml z fungující nové jednotky s tím že jsem musel opravit názvy sulphur_xx99_999999999 na odpovídající a taky velikosti souborů. Očekával jsem, že pokud to bude OK tak začnu někde na 40 % jako u nové jednotky. Byl jsem překvapen, protože normálně se vše spustilo a zřejmě i tam kde přestal, dokonce i trickly odesílá. Ovšem není vidět, že by je server přijal a nějak započítal, tak nevím. Mám zatím 66,8 %, a odeslal jsem už dva. Kdyby tam naskakovaly tak jsem klidný a jedu dál, ale teď fakt nevím, jestli mám počítání úplně dokončit do 100% nebo nemarnit čas. Třeba jen výsledek odešle, ale někam do vzduchoprázdna. Na co se mám ještě podívat?
Ještě abych upřesnil, vždy jedu pod Boincem jen jeden projekt, pokud chci nějaký jiný, tak ukončím počítání, přejmenuju adresář boinc na boinc2 a ten žádaný na boinc a jedu jiný projekt a to třeba mám dva adresáře na SETI a teď vlastně i na CPDN.
Začal jsem tedy počítat novou jednotku. Už mám přes 40 %, tak jsem začal porovnávání abych zjistil , který soubor jsem ztratil. Byl to sulphur_xx99_999999999.zip z adresáře climatepredictin.net, podíval jsem se, co je v něm zazipované a vytvořil jsem si ho znovu. Ovšem nebylo to to pravé ořechové. Dalším bádáním jsem vymyslel nahradit soubory client_state.xml a sched_request_climateprediction.net.xml z fungující nové jednotky s tím že jsem musel opravit názvy sulphur_xx99_999999999 na odpovídající a taky velikosti souborů. Očekával jsem, že pokud to bude OK tak začnu někde na 40 % jako u nové jednotky. Byl jsem překvapen, protože normálně se vše spustilo a zřejmě i tam kde přestal, dokonce i trickly odesílá. Ovšem není vidět, že by je server přijal a nějak započítal, tak nevím. Mám zatím 66,8 %, a odeslal jsem už dva. Kdyby tam naskakovaly tak jsem klidný a jedu dál, ale teď fakt nevím, jestli mám počítání úplně dokončit do 100% nebo nemarnit čas. Třeba jen výsledek odešle, ale někam do vzduchoprázdna. Na co se mám ještě podívat?
Ještě abych upřesnil, vždy jedu pod Boincem jen jeden projekt, pokud chci nějaký jiný, tak ukončím počítání, přejmenuju adresář boinc na boinc2 a ten žádaný na boinc a jedu jiný projekt a to třeba mám dva adresáře na SETI a teď vlastně i na CPDN.
Indy, takt o neni zrovna jednoduche.
Jestli jsi predelaval nebo jinak prenasel sched_request, tak je potreba spravne synchronizovat hostID a predevsim cislo RPC sekvence. Jinak pri dalsi kontaktu se scheduler vytvori novy HostID, coz se ti asi prihodilo.
Jukni do profilu, jestli tam proste nemas vygenerovanou novou masinu...tedy pokud jsi to jiz nedelal.
EDIT: jsem trubka - jsi poslal link, tak to muzu udelat sam. Jo, mas tam vygenerovanou novou masinu, jak jsem predpokladal.
Ta nova masina udelala na starem modelu jeste 2 trickle a ted uz pocita dalsi model - http://climateapps2.oucs.ox.ac.uk/cpdnb ... id=1886477 a trickle jsou aktualni.
Zahada vyresena?
Jestli jsi predelaval nebo jinak prenasel sched_request, tak je potreba spravne synchronizovat hostID a predevsim cislo RPC sekvence. Jinak pri dalsi kontaktu se scheduler vytvori novy HostID, coz se ti asi prihodilo.
Jukni do profilu, jestli tam proste nemas vygenerovanou novou masinu...tedy pokud jsi to jiz nedelal.
EDIT: jsem trubka - jsi poslal link, tak to muzu udelat sam. Jo, mas tam vygenerovanou novou masinu, jak jsem predpokladal.
Ta nova masina udelala na starem modelu jeste 2 trickle a ted uz pocita dalsi model - http://climateapps2.oucs.ox.ac.uk/cpdnb ... id=1886477 a trickle jsou aktualni.
Zahada vyresena?
Řekl bych, že to ještě vyřešeno není, protože ty dva trickly jsou staré - 28.2.2006, já teď po těch opravách zasílal 9.5.2006 další dva a ty nikde nejsou.
Hledal jsem, kde je uloženo číslo Work Unit ID případně Result ID, ale našli milí rádcové? Nenašli. Aspoň zatím.
Zajímalo by mě, co přesně odesílá a podle čeho pozná k jakému projektu trickly patří. Řekl bych, že odesílá vše dle souboru sulphur_ei55_000676697.xml, který obsahuje vše, co se má odeslat. Ten byl určitě bez poruch a podadresáře taky.
Zkusím určitě dopočítat do 80%, až se ukončí fáze 4, pak se třeba uvidí.
Hledal jsem, kde je uloženo číslo Work Unit ID případně Result ID, ale našli milí rádcové? Nenašli. Aspoň zatím.
Zajímalo by mě, co přesně odesílá a podle čeho pozná k jakému projektu trickly patří. Řekl bych, že odesílá vše dle souboru sulphur_ei55_000676697.xml, který obsahuje vše, co se má odeslat. Ten byl určitě bez poruch a podadresáře taky.
Zkusím určitě dopočítat do 80%, až se ukončí fáze 4, pak se třeba uvidí.
