Stránka 2 z 2

Napsal: pát kvě 12, 2006 8:32 pm
od Honza
Sulphur uz zadne nemam, ale myslim, ze Carl struktura tricklu zasadne nemenil (tedy krome moznosti jej mit 64+Kb a podobne).
Navic ani nikde nemam zadny neodeslany trickle (vsechno jde rovnou), abyc to overil.

Pokud tedy budu spolehat na svou nespolehlivou pamet, tak v trickle souboru jsou opravdu vsechny potrebne informace. Uz do dob klasika CPDN je znaceni modelu v nejake podobe jako ted (kombinace oznaceni typu modelu, souboru parametru a pripadne poradoveho cisla) a do WorkUnitID a ResultID se to rozkodovava az na serveru. Ale klidne muzu kecat, protoze ta pamet...

Trochu off-topic...tedy vlastne jenom vuci tvemu prispevku, ale jinak velmi on-topic.
5.4.9 by snad mela umet pri startu restaurovat poskozeny client_state.xml z client_state_prev.xml ...ale nezkousel jsem to :lol:

Napsal: sob kvě 13, 2006 4:29 pm
od forest
Honza píše: Trochu off-topic...tedy vlastne jenom vuci tvemu prispevku, ale jinak velmi on-topic.
5.4.9 by snad mela umet pri startu restaurovat poskozeny client_state.xml z client_state_prev.xml ...ale nezkousel jsem to :lol:
Tak tohle by pomohlo řešit problémy spousty lidí, kterým se model odporoučí právě díky poškození client_state.xml, což se i mně už 2x stalo, když u nás vyskočil jistič :?

Napsal: sob kvě 13, 2006 9:09 pm
od Honza
forest píše:Tak tohle by pomohlo øešit problémy spousty lidí, kterým se model odporouèí právì díky poškození client_state.xml, což se i mnì už 2x stalo, když u nás vyskoèil jistiè :?
Se nediv, ze ti vyskocil jistic, kdyz jsi mel doma overclockunty Presshot :lol:
Jak rikam, nezkousel jsem, ale mohlo by to v nekterych pripadech pomoci...

Napsal: ned kvě 14, 2006 9:20 am
od forest
:lol:
Vyskočil vždy jen když jsem se amatérsky hrabal v elekrice na baráku a podařilo se mně něčím propojit drátky :oops:

Client state

Napsal: stř kvě 31, 2006 5:43 pm
od Indy
Takže jsem včera dopočítal těch 80%, ukončil jsem počítání, zazálohoval adresář, pak znovu spustil, abych to odeslal. K mému překvapení boinc nahlásil opět chybu, napsal 100% a hotovo. Zjistil jsem však jednu zajímavou věc - názvy tricklů v adresáři měly hned za názvem "sulphur_ei55_000676697" ještě "_1", ale sbalený zip soubor po čtvrté fázi "_0". Bohužel se stalo asi to, že původní porušený projekt měl na konci za názvem "_0" a potom nový stažený "_1", já nevěděl, že v tom může být rozdíl a vnutil jsem mu počítat data dál s tou jedničkou na konci, ikdyž můj workunit tam měl mít 0. Proto mi tam taky ty trickly průběžně nenaskakovaly - byly odlišné. Provedl jsem tedy další úpravu client_state a nahradil ty jedničky nulama, opravil název posledního tricklu - změnil jsem v názvu tu 1 na 0 a zkusil to odeslat. Boinc opět hlásil asi 5 chyb, že nemůže najít nějaké soubory, ale trickl odeslal a odeslal i zip soubor po čtvrté fázi. A světe div se, ten trickl se mi tam i objevil a dnes dokonce i body ( asi 3100, jako by se nic nestalo viz http://climateapps2.oucs.ox.ac.uk/cpdnb ... id=1352716 )
Otázka tedy zní:
1. Kam chodily ty trickly s jedničkou v názvu a mohly někomu jinému poškodit jeho výsledky?
2. Ikdyž dopočítám vše do konce, využije se nějak výsledek, bude-li tam napsáno, že je tam chyba "client error" ?

P.S.: Máte-li někdo ještě jednotku sulphur_xxxx_999999999 a za ní "_0", pošlete mi prosím client_state na porovnání na indy@wo.cz , dík.

EDIT: Omlouvám se, mělo to být v threadu "client_state.xml poškozen - možnost opravy?"
EDIT2: Díky za přesun :-)

Napsal: stř kvě 31, 2006 6:35 pm
od Honza
Je urcite potesujici, kdyz se to podari alespon trochu opravit.

ad 2 - server vysledky prijde bez ohledu na "state". Pro dalsi zpracovani jsou dulezite uploadovane soubory, ne trickle. V novejsich modelech uz se trochu stira rozdil mezi uploadem a trickle soubory, resp. trochu meni vyznam. Upload soubor muze v podstate obsahovat restart dump (neco jako checkpoint, od ktereho lze pocitat dal) a trickle uz neobsahuji pouze udaj o tom, kde se dany model ve vypoctech nachazi, ale i nejake zakladni udaje o vysledcich (drive mega-trickle).
ad 1 - na to nedokazi presne odpovedet, sulphur uz zadny nemam a podrobnosti si nepamatuji.

Re: Client state

Napsal: stř kvě 31, 2006 6:54 pm
od LiborA
Indy píše:P.S.: Máte-li někdo ještě jednotku sulphur_xxxx_999999999 a za ní "_0", pošlete mi prosím client_state na porovnání na indy@wo.cz , dík.
Mám rozpočítané ještě tři SC:
sulphur_ilyp_100868273_0 a sulphur_ix34_100882688_1 a sulphur_ilrs_100868024_0
Ty první dva jsou dosud OK, ten poslední již spadnul a počítám ho ze zálohy - už na 3 kompu :)
Takže pokud nějaký chceš, mohu klidně poslat, stačí si vybrat který 8)

Re: Client state

Napsal: stř kvě 31, 2006 7:11 pm
od Indy
LiborA píše:Takže pokud nějaký chceš, mohu klidně poslat, stačí si vybrat který 8)
Beru tedy ten první, díky. Pak svoje opravím a dopočítám, ať můžu klidně spát :D

Poškozený client_state.xml

Napsal: ned čer 04, 2006 11:36 am
od Indy
Takže velký dík všem, a to i za starší postřehy - z toho jsem vycházel. Počítám už bezproblémů to co mám, trickly se také odesílají, viz http://climateapps2.oucs.ox.ac.uk/cpdnb ... id=1352716 , takže pokud to zase nějakým zásahem nezruším, tak nejpozději do konce června budu konečně s první jednotkou u CPDN hotov. :Honza_clap :Honza_clap :Honza_clap
Důležité je, že pokud se neporuší soubory z adresáře climateprediction.net ( a vlastně nějaké ty zipy klidně mohou :D ), tak by to mělo zpravidla jít opravit.