Forum boinc.cz

WOW! Dostal jsem prvni sponzorsky dar na vyvoj Boinc klienta! A navic od Cecha, cehoz si vazim dvojnasobne (ne-li jeste vic nez dvojnasobne), protoze dobre vim, ze rozdil prijmu na Zapade a v CR je porad znacny. Akorat nevim od koho z vas to je, protoze tam vidim jen skutecne jmeno a ne Boincovsky alias, takze nevim komu mam podekovat a udelit darcovskou hvezdicku (). Sice mam dojem, ze mi to jmeno neco rika, ale nejak si ho nemohu zaradit k zadnemu aliasu.

Kazdopadne diky!!!

2trux: Asi ti nebudu říkat nic novýho, nejspíš už si na to přišel, ale pochlubit se musím Odhalil sem jakže to je s těma parametrama v global_prefs. Je to tak, že když má host přiřazenou nějakou roli, pro kterou sou na webu oddělený preference, řídí se pouze parametrama uvedenejma v bloku "venue"a tudíž ty tvoje parametry na začátku global_prefs ignoruje. Jakmile pro danou roli nastavení nejsou (no separate prefs for work; using your defaults), vezme global_prefs od začátku a narazí na tvoje parametry.

Jojo, ja vim, to je presne co jsem mel na mysli ve svojem predchozim prispevku. Puvodne, bez dukladneho studovani kodu, jsem byl pod dojmem, ze ta globalni cast se cte vzdycky, i kdyz je venue definovana, a pak teprve se precte venue a tim se ty default parametry prepisi. Bohuzel to byl mylny dojem. Tak hrozne to ale neni, takto to alespon budu muset udelat poradne a bude to flexibilnejsi.

nejak jsem prehlid verzi 5.3.8 o ktere se tu porad mluvi, vidim jen 5.3.6 nebo http://boinc.berkeley.edu/dl/cpdnbbc_5. ... telx86.exe

jak jak to je?

Tak nakonec jsem to s tim global_prefs.xml konfiguracnim souborem uplne vzdal. Cim vic jsem to zacal menit, tim vic se zahustovaly problemy. Ten soubor a funkce s nim spejene proste nejsou urceny na tento ucel a to predelani by stalo vic casu a namahy nez to za takovou prkotinu stoji. Nakonec jsem tedy vsechny sve parametry premistil do noveho souboru truxoft_prefs.xml. Pokud je mate v global_prefs.xml nebo dokonce i ve starsim formatu v remote_hosts.cfg, tak se nemusite o nic starat - ono je to precte a ten soubor to vytvori samo. Pokud to instalujete poprve, vytvorte ten soubor v Notepadu, nebo pomoci zkopirovani jineho a pak tam ty parametry natlucte - priklad je na strance na mem serveru.

Je tam tedy ted verze 5.3.8.tx24 (ano, puvodne tam bylo omylem napsano 5.3.6.tx23 - tedy 6 misto 8, ale soubor tam byl spravny)

taky by mě zajímalo co je to ta 5.3.9, jo a vypustili nový grid republic, ale ještě jsem to nestáh tak nevím

Zkouším tx24:
S tou zpětnou kompatibilitou bych to nepřeháněl. Prostě nová verze, novej způsob konfigurace, tak ať si to lidi přepíšou. Starej způsob byl zavrhnut páč s ním byly problémy, a problémy sou zdá se i se zpětnou kompatibilitou. Když dám všechno do truxoft_prefs, a všude jinde odmáznu, chodí to jak má. Ale že by si to z global_prefs přečetlo a do truxoft_conf zapsalo to se mi nepovedlo ani jednou, navíc se to stejně chovalo nějak prapodivně. Bralo mi to jen jeden z parametrů, nebo vůbec žádnej, ale oba zároveň (return_results, calibrate_credit) ani jednou.
Chápu snahu o zpětnou kompatibilitu, ale stejně ji nejspíš nemůžeš udržovat věčně. Takže bych se nesnažil uživatele chlácholit zpětnou kompatibilitou, ale naopak bych je tlačil k používání novýho způsobu konfigurace a zastaralý způsoby postupně s novejma verzema vypouštěl.

Kalibrování kreditu: V případě že nemá comp trvalej přístup k síti, spočítá pár jednotek a pak je odesílá a reportuje naráz. U všech napíše CC calibration: blocked [negative calibration limit]. U další jednotky sem si dal bacha aby ta síť byla, proběhl upload, proběhl report a tuhle hlášku si to odpustilo. tedy otázka:
Je nutnost pro správnou funkčnost kalibrace mít neustálej přístup k síti? Či čím vzniknou tyhle hlášky?

EDIT: koukám na ty jednotky na webu. Před zapnutím kalibrace sem žádal tak deset kreditů za jednotku, postupně to narůstalo, včera večer sem byl tak na sedmnácti. Přes noc zakázaná síť, ráno deset jednotek s hláškou CC calibration: blocked, všechny jednotky žádaly standartních 10 kreditů. Ta jedenáctá, bez žádný hlášky žádá zase 10. Znamená to že se tou hláškou resetuje celej proces kalibrace a začíná to nanovo od začátku?

EDIT2: Taky sem teď zkusil priority_projects.
Prvně otázka: Je to case sensitive? Ve výpisu hlášek z magora je všechno malejma (einstein@home), v stdoutdae.txt jsou použity velký písmena (Einstein@Home)
Mám připojený dva projekty, SETI a Einstein, přičemž SETI už dýl nepočítám, měl sem pozastavený přijímání práce. Teď si říkám že dám Einstein jako prioritní projekt a SETI zase povolím. Přidal sem příslušnej parametr (jméno projektu psaný malejma písmenama), při startu mi to napsalo příslušnou hlášku a po povolení přijímání práce pro SETI si to u SETI o tu práci řeklo. Udělal sem něco blbě, nebo to nezafungovalo tak jak mělo?

EDIT3: Tak priority_projects u mě nepracuje jak bych si představoval. Od SETI sem se odpojil a připojil znovu, stáhlo si to jednu jednotku a víc nechtěl, zdálo se že by to mělo bejt OK. U Einsteina je práce dostatek, v zásobě mám pořád pár jednotek, ovšem narazil sem na tohle: načež SETI okamžitě zareagovalo tímto: Očividně to tedy reaguje na zprávy serveru (no work from project) a nikoliv na skutečnej stav práce kterou mám k dispozici na disku. Navíc druhej projekt žádá práce dle svýho uvážení (nesmyslně moc). Líbilo by se mi kdyby od druhýho projektu žádal třeba jen jednu sekundu práce - tedy by dostal jednu jednotku a po dopočítání zkusil o práci požádat zase prioritní projekt.

Ta zpetna kompatibilita funguje dobre, pokud ale mas oba soubory,tak se to muze hadat. Takze lepsi je spolehnout se bud na jedno nebo na druhe.

Pristup k siti vztah ke kalibraci nema zadny. Koeficienty kalibrace se mohou vynulovat pri manualnim editovani nekterych souboru, nebo pri spusteni benchmarku, a pak to zase chvili trva, nez se zase doladi.

Jmena projektu nejsou case-sensitive, muze to byt malymi i velikymy pismeny.

Priorita projektu ridi zatim jen spousteni jednotek, nikoli tahani prace. Neni to mysleno na nejake pravidelne prepinani projektu - na to mnohem jednoduseji muzes pouzit jiz dostupne prikazy k pozastaveni projektu. Je to spise mysleno tak, ze ty zalozni projekty jsou dlouhodobe potlaceny a zaktivovany jen v pripade nedostatku prace pro primarni projekt. Protoze se ale pripade kdy jede primarni projekt, naprosto ignoruji deadline zaloznich projektu, muze to mit dost casto za nasledek, ze stazene jednotky uz budou prosle. To je ale vice-mene chtene chovani. Resit to bude dalsi planovana zmena - automaticke mazani jednotek v zasobe, ktere uz jsou prosle, nebo nemaji sanci byt zpracovany vcas. Na tom ale zatim jeste nepracuju, jen to mam v planu. Pokud to stahuje praci i pro neaktivni zalozni projekty, tak s tim ale zkusim neco udelat jeste v tehle verzi - to by nebylo moc dobre.

Přístup k síti versus kalibrace: Taky se mi to zdá divný, ale s povoleným přístupem mi tu hlášku nenapsala ani jedna jednotka, se zakázaným všechny. Zkouším a dělám pokusy. Tohle můžeš snadno zkusit i sám, zakaž přístup k síti a počítej, uvidíš. Třeba de u mě jen o náhodu, ale postupem času mi to připadá pravděpodobný čím dál míň
priority_projects sem teda asi špatně pochopil. Jak by se mi líbilo aby to fungovalo sem psal, takhle to pro mě nemá význam.
Taky už mám spočítáno pár jednotek Einsteina. S nekalibrovanou tx12 sem žádal kolem 70-ti kreditů za jednotku, s tx20+ se to drží 66,5. Že by se to někam hejbalo mi nepřipadá. Zajímavý taky je že benchmarky tx12 i tx24 sou prakticky identický, takže ten rozdíl v kreditech je spíš způsobenej rozdílným benchmarkem než kalibrací. Nijak sem si nedával záležet aby comp v době spouštní benchmarku tx20 byl nevytíženej, spíš právě naopak.

To s tou siti mi nedava moc smysl - zadna souvislost tam (alespon na prvni pohled) nemuze byt, ale pokud je to reprodukovatelne, pak se na to rozhodne podivam.

Co se tyce toho prioritniho projektu - to bylo takhle vyzadano, ale nebranim se pridani dalsich funkci nebo modu, pokud to nebude vyzadovat vic prace nez uzitku. Napady a navrhy si davam na seznam k udelani, ale samozrejme ne na vsechno najdu cas a silu.

Ta kalibrace u jinych projektu nez S@H muze byt omezovana negativnim limitem, ktery byl stanoven prilis tesne. Ted jsem ho u verze 5.3.8.tx25 zmenil, tak to prosim zkus. Kdyby to porad nefungovalo, rekni mi presne jaka kalibracni cisla vidis v hlaskach.

Myslím si že to zvolení prioritního projektu, pokud to bude fungovat/či funguje, jak popisoval Trux, je velice užitečná funkce hlavně pro PC ke kterým se nedostaneš Mirasi každým dnem.
Jestli jsem to pochopil správně, přihlásím se na daném PC v klientovi do dvou projektů a jeden z nich zvolím jako prioritní. Pokud bude mít stále práci, bude v provozu pouze tento projekt a druhý nepojede, ani si nebude stahovat žádnou práci. V případě že prioritní projekt nebude náhle mít co počítat (a to z jakéhokoliv důvodu) druhý projekt si stáhne práci a bude počítat dokud prioritní opět nebude mít něco na zpracování.

Bohužel na tohle testování nemám vůbec čas, tak se omlouvám že ti s tím Truxi nepomůžu, ale snad se najde dost jiných členů co si s tím rádi pohrajou a budou testovat.
Držím palec

No, Miras ma pravdu, ze u zalozniho projektu je lepsi vyzadovat jen minimum prace, jinak se to moc predzasobi a pak tam budou zbytecne zavazet prosle jednotky. Zkusil jsem to zmenit ve verzi 5.3.8.tx26, kterou jsem ted dal online. Netestoval jsem to - je docela mozne, ze to bude potrebovat jeste vice zmen, takze pokud nekdo mate moznost to vyzkouset, byl bych rad. Melo by to u zaloznich projektu, jak Miras navrhoval, vyzadovat jen 1s prace, coz obvykle stahne jednu WU. Mozna budu muset jeste zmenit prioritu requestu, ale myslim, ze by to takto mohlo taky fungovat.

Zkoušel sem nějak nasimulovat tu síť+kalibraci, ale teď zrovna se nějak nedaří. Tak to snad opravdu byla jen náhoda. Každopádně přes noc bude noťásek opět bez sítě, tak sem zvědavej na ráno

Prioritní projekt už je zase o kus dál, povolil sem SETI přijímat práci a řek si o sekundu. Úplně optimální by bylo, aby práci opravdu žádal až tehdy když prioritní projekt nemá na disku ani jednu jednotku a server nic nepošle, ale takhle je to taky dobrý. Ale rozhodně je tohle rozumnější než žádat práce zbytečně moc.

Jednotka Alberta mi trvá něco ke čtyřem hodinám, takže to testování je krapet zdlouhavější. U těch jednotek který sem za ten zhruba den ale kalibrace pravděpodobně proběhla OK, magor žádnou hlášku nepsal. Du se trochu porejpat v souborech.

EDIT: Jo, tak ten prioritní projekt sem přechválil Řekne si sice jen o jednu sekundu práce. Ale každejch deset minut, tak dlouho dokud zase nenakešuje práce na x dní.

S tim prioritnim projektem to melo fungovat tak, ze si o praci skutecne rekne jen kdyz neni nic pro hlavni projekt. Bohuzel, je to asi jeste nekde jinde, nez jsem videl - tahle cast je v kodu hodne neprehledna. Rozhodne to tak nenecham.

Co se tyce kalibrace, tak pri odesilani jednotky by v hlaskach vzdycky mela byt jedna s detaily o provedene kalibraci. Jinak je to samzrejme ve vysledcich na webu taky (ale jen pokud je kalibrace pro dany projekt nastavena). Pokud tam nikde zadne detaily nejsou, tak bud nefunguje zapinani nekterych projektu (ale ostatnim to zatim funguje), nebo mas nejakou chybu v syntaxi v konfiguracnim souboru.

trux píše:Co se tyce kalibrace, tak pri odesilani jednotky by v hlaskach vzdycky mela byt jedna s detaily o provedene kalibraci.

Tak tím sem si naprosto jistej, že ve výpisu hlášek v magorovi sem detaily o kalibraci ještě neviděl. S vyjímkou situace, kdy je kalibrace zablokovaná. Ale to že kalibrace proběhla úspěšně nepíše. Na webu sou informace o kalibraci taky jen tehdy když se povede, v případě neúspěchu tam o kalibraci není ani zmínka. Že mám kalibraci zapnutou sem si ověřil v stdoutdae.txt, kde sem našel hlášky podobný týhle: 2006-01-14 08:19:12 [einstein@home] CC calibration: blocked [negative calibration limit] 65.54 >> 34.55 (time: 15614s >> 8163s / Gfpops: 1.85 >> 1.91)

Ale ta kalibrace by tady byla docela brutální. Porovnám li to se SETI, tak tam mě spočítání jednotky zabere zhruba 2 hoďky. Za to bych měl vyfasovat 32 kreditů. Jednotka Alberta trvá přes čtyři hodiny, žádá 65 kreditů, takže mi to přijde jako docela fér. S kalibrací by si řek o polovinu...