Forum boinc.cz

Mam novou verzi 5.3.6.tx20, ale tentokrat je to uplne neco jineho. Neni ani moc agresivne optimalizovana - je to jen jedna verze pro vsechny procesory, ale kalibruje vysledky u kazdeho projektu zvlast (nebo jen u zvolenych). To znamena, ze u S@H jednotek s plnou delkou pozaduje (v idealnim pripade) kredit kolem 32, coz je kredit referencni jednotky spustene na referencni masine (1Gflops/1Giops).

Vice detailu je v anglictine na foru S@H: http://setiathome.berkeley.edu/forum_th ... p?id=26623
Ted uz nemam silu to psat jeste znova cesky.

Zatim to jeste testuju a cekam az zase nahodi servery, ale vypada to, ze to funguje dobre. Kdyz nebudou zadne velike protesty, tak tu verzi pak nejdriv uvolnim tady, a po nejakem case testovani teprve verejne na mych strankach.

EDIT: zapomel jsem - pokud chcete, abych tu verzi vydal, tak prosim kliknete na ten link na diskuzi na S@H foru a hlasujte tam pro - kliknutim na to male zelene plus, uplne dole, pod mym zacatecnim prispevkem.

Chtel jsem neco z informaci na tom original thread prenest sem a nejak to shrnou v CZ, ale bohuzel SETI [opet] nejede.
Thread jsem si asi pred 2 hodinama precetl, ale shrnout to z hlavy si uplne netroufam, abych nejak neposunul vyznamy.

Zatim tam bylo asi 35 hlasu pro vydani takoveho BOINC-core; trux samosebou prislibil vcetne zdrojaku, jak ma dobrym zvykem.
Diskuse se vedla kolem uspesnosti takoveho postupu...kde brzdou jsou zatim predevsim nefunkcni servery SETI, aby to mohl trux otestovat lepe 'in-house'.
Obavy spocivali predevsim v manipulaci s correction_factorem a vyslednym casem jednotky...ale presne na tohle chtel trux od ucastniku (a doufaje i od BOINC tymu) slyset nazory predtim, nez neco takoveho pusti do sveta.

Neni mi zcela jasny mechanismus, jak se budou kalibrovat ruzne jednotky u ruznych projektu - nebo i ruzne jednotky v ramci stejneho projektu...
EDIT: Jestli spravne chapu diskusi na SETI, bude treba jit cestou 'upravy' benchmarku za ucelem spravedliveho narokovani kreditu, nebot server muze prilis vysoky CPU time odmitnout

Co se tyce toho kalibrujciho klienta, tak pomocny vyvojar Ingleside me upozornil na to, ze server loguje inkonzistence v nahlasovanem casu hotovych jednotek - k tomu by v soucasne stavu toho klienta skutecne mohlo dochazet, takze s tim jeste asi neco budu muset udelat. V podstate jsou dve moznosti - bud prizpusobovat hodnoty benchmarku, nebo pozmenit ty upravy vypocetniho casu tak, aby to zadne inkonzistence nevybuzovalo. Prvni (benchmarky) neni prilis dobre z hlediska jednotlivych WU; druhe (CPU cas) by znamenalo mozna az prilis divoke sachy - nejen zmeny vypocetniho casu, ale i modifikace casu ukonceni prip. odesilani vypoctu, a mozna i zmena poctu nahlasovanych procesoru. To mi uz pripadne, ze bych do toho vnasel uz prilis chaosu, takze asi preci jen si budu muset vystacit s temi benchmarky. No nic, vidim, ze s tim bude jeste dost prace. Mozna nakonec prijde driv S@H Enhanced a bude hned fungovat, a tim padem bude (aspon docasne) po starostech se spatnymi kredity.

trux píše:No nic, vidim, ze s tim bude jeste dost prace. Mozna nakonec prijde driv S@H Enhanced a bude hned fungovat, a tim padem bude (aspon docasne) po starostech se spatnymi kredity.

Link na kod od Ingleside jsem videl. Jo, je to dost zasadni rozhodnuti a znamena to dost prace.
S@H Enhanced na Bete vysel, ale (i) nejakou dobu jeste podle mne potrvani, nez bude distribuovan na SETI, (ii) zpocatku bude soubezny chod obou aplikaci - hadam ze tydny az mesice. [otazkou taky je, jestli nekteri SETI useri nebudou odstreloval Enhanced WUs v domeni toho, ze je neco spatne protoze to bezi dlouho, s obavem z toho ze za to dostanou malo kreditu (zvyk ze zombie) atp.].
Neresi to vubec projblem na Rosette - i kdyz k tomu se lze postavit at si to vyresi sami v ramci aplikace (ale zase neni jejich chyba, jak nevhodne se kredit v BOINC prideluje).
Je Einstein o neco bliz zavedenim FLOPs counting do aplikace?

tak jsem na vetsine kompu nasadil truxe a od te doby jdou vypocty, nebo spis body za vypoctene jednotky rapidne dolu
viz
http://www.boincsynergy.com/stats/teams ... roject=pah

cim to? ze by to predictor pocital jinak?

2trux: Možná bych toho chtěl moc, ale za zeptání se nic nedám . Ne každej má to štěstí a možnost kontrolovat svý kompy "zvenku" z pevný IP adresy. Nešla by spáchat modifikace, aby boinc nekontroloval IP (remote_hosts.cfg), ale jen heslo (qui_rpc_auth.cfg)?
Alternativním řešením by mohla bejt možnost povolování rozsah IP adres v remote_hosts, nicméně první varianta by byla příjemnější.

sj-shark píše:cim to? ze by to predictor pocital jinak?

O zpusobu pocitani kreditu u Predictoru nevim vubec nic, ale projekty maji moznost pocitat kredity ruznymi zpusoby: pevne (jako u CPDN), zavisle jen na case, zavisle na poctu operaci (S@H Enhanced), zavisle na souctu dhrystone a whetstone (S@H), nebo na preddefinovanem pomeru dhrystone a whetstone. V pripade, ze by Predictor pouzival vysoky koeficient silne uprednostnujici whetstone, pak by to bylo celkem pochopitelne, protoze muj klient kompilovany MSIE ma mnohem silnejsi dhrystones - whetstones jsou o hodne pozadu za klientem kompilovanym Intel kompilerem, jako je ten od Crunch3ra.

Miras píše:2trux: Možná bych toho chtěl moc, ale za zeptání se nic nedám . Ne každej má to štěstí a možnost kontrolovat svý kompy "zvenku" z pevný IP adresy. Nešla by spáchat modifikace, aby boinc nekontroloval IP (remote_hosts.cfg), ale jen heslo (qui_rpc_auth.cfg)? Alternativním řešením by mohla bejt možnost povolování rozsah IP adres v remote_hosts, nicméně první varianta by byla příjemnější.

Moznost uplne odstranovat IP adresy bych rozhodne nepridaval. A ani to neni potreba. Je nekolik reseni - napr:

• bezpecnejsi - porid si dynamicke jmeno domeny (napr u dyndns.rog) a pouzij jej misto IP adresy
• jednodussi - zadej castecnou IP adresu (blok adres). Pokud mas momentalne adresu napr. 85.123.21.42 zadej 85.123.21 - to pak umozni vsech 255 adres v tom bloku. U vetsiny poskytivatelu pripojeni jen ten rozsah vetsinou vetsi, takze muzes bud zadat jeste vetsi blok: 85.123, nebo radeji nekolik mensich bloku 85.123.21, 85.123.22, 85.123.23,... (kazdy na samostatne radce)

Obě řešení maj svý pro i proti.
ad1 - v případě neveřejný IP tím stejně povolím přístup všem, co se mnou IP sdílejí.
ad2 - konkrétně u mě, bych musel povolit rozsah 85.16x.xxx.xxx. To už je sakra hodně IP

Možná mě plně nedocházejí bezpečností rizika, ale co útočník získá tím, že se mi connectne na boinc? Zdá se mi to prostě zabezpečený až moc. Musím znát IP kam se připojuju, musím znát heslo, ale když si sám předtím na daným compu přístup nepovolím, neškrtnu si. Kontrola IP mi přijde jako docela nešťastný řešení, proč nestačí klasický jméno/heslo?

Nijak extra mě to netrápí, žil sem s tím doteď, budu žít i dál, jak říkám, jen sem se zeptal . Občas si prostě říkám, že by se hodilo připojit se a něco provést, jenže to nejde...

Nikoli! Heslo musis pouzivat tak jako tak, IP adresa nebo domena je jen pridavna, ale dost dulezita bezpecnost a proto cim vic ten rozsah adres muzes omezit, tim lip - z toho hlediska je skutecne lepsi dynamicke jmeno domeny.

Bezpecnostnim rizikem je kazdy otevreny port - staci mala chyba v boinc klientu nebo ve Windows socketu a je na problemy zadelano. A i kdyz by nikdo zadnou diru nenasel, da se ten otevreny port velmi dobre zneuzit na "DoS-ovani" (utok stylu Denial of Service) at jiz umyslne a cilene na BOINC, tak i jako vedlejsi ucinek na Internetu velmi bezneho skenovani portu.

A to, ze by jsi pouzitim dynamicke adresy otevrel cestu i ostatnim, kteri jsou s tebou na stejnem routeru (a tedy pouzivaji stejnou verejnou IP), je take spatne. Pocitace, ktere sdileji verejnou adresu, na sebe navzajem nepristupuji pres internet, ale pres LAN, jinak by zadne verejne sluzby nemohly na jednotlivych stanicich LANu vubec fungovat. A navic v takove siti ani nemuzes mit zadny server (coz BOINC klient v pripade obsluhy RPC je) bez vedomi spravce routeru, protoze bys na routeru musel nejdriv nastavit, ktera ze sdilenych adres bude dostavat pozadavky pres port 1043 (nebo jiny pouzity RPC port). Router to rozhodne nebude posilat vsem.

trux píše:

sj-shark píše:cim to? ze by to predictor pocital jinak?

O zpusobu pocitani kreditu u Predictoru nevim vubec nic, ale projekty maji moznost pocitat kredity ruznymi zpusoby: pevne (jako u CPDN), zavisle jen na case, zavisle na poctu operaci (S@H Enhanced), zavisle na souctu dhrystone a whetstone (S@H), nebo na preddefinovanem pomeru dhrystone a whetstone. V pripade, ze by Predictor pouzival vysoky koeficient silne uprednostnujici whetstone, pak by to bylo celkem pochopitelne, protoze muj klient kompilovany MSIE ma mnohem silnejsi dhrystones - whetstones jsou o hodne pozadu za klientem kompilovanym Intel kompilerem, jako je ten od Crunch3ra.

neslo by to nejak zjistit? moje anglictina neni tak dobra abych se tim prohrabal
diky moc

sj-shark píše:neslo by to nejak zjistit? moje anglictina neni tak dobra abych se tim prohrabal

Soude podle linearni zavislosti CPU time a claimed credit na results page bych typoval na klasicky benchmark*CPU+time. Toto hlediska je vhodne, pokud jsou WUs ruzne dlouhe, coz je prave pripad predictora.

Honza píše:

sj-shark píše:neslo by to nejak zjistit? moje anglictina neni tak dobra abych se tim prohrabal

Soude podle linearni zavislosti CPU time a claimed credit na results page bych typoval na klasicky benchmark*CPU+time. Toto hlediska je vhodne, pokud jsou WUs ruzne dlouhe, coz je prave pripad predictora.

ja si nemuzu pomoct, ted jsem se koukal kolik jsem dostaval bodu predtim, kolem 10-11 ted mam 5-7 zkusim dam bez optimalizace a uvidim co to udela

Pokud nekdo mate zajem otestovat moji novou verzi, tak jsem ji soupnul k sobe na server. Ma tedy jiz tu ohlasovanou kalibraci kreditu a tudiz jsem to kompiloval univerzalne bez nejake velike optimalizace, a benchmarky jsou tedy celkem normalni - to ale pro konecny kredit u S@H v pripade zapnuti kalibrace neni nutne. Naopak, prave to, aby bechmarky byly nizke, byl ucel, aby se tim tak zabranilo prehaneni kreditu (a pripadne penalizaci) u jinych (neoptimalizovanych) projektu.

Tato verze ma ale i spoustu dalsich novych funkci. Celkove je tam toho predelano uz docela dost a zmeny jsou jiz pomerne rozsahle a komplikovane. Rikam to proto, ze se tim padem da pocitat i s vetsimi problemy, nez kdyz se delaji jen male upravy. Navic jsem jeste nemel sanci vsechno poradne odzkouset, takze pokud to chcete otestovat sami, budte opatrni a udelejte si radsi backup boinc adresare. Taky mozna zatim radsi opatrne na pracovnich nebo jinych dulezitych masinach. Samotnemu mi to sice bezi bez problemu na 5 pocitacich, ale to jeste neznamena, ze tam nemuze byt nejaky zly bug.

Ke zmenam tady jen strucne (detaily jsou popsany anglicky na http://boinc.truxoft.com/core-cal.htm a cesky v readme.cz.txt v zip souboru)
- konfigurovatelny RPC port (stare)
- return_results_immediately (stare)
- prirazeni CPU afinity u multiprocesorovych a HT masin (stare)
- prirazeni priority procesu u jednotlivych WU (stare)
- kalibrace kreditu (NOVE v 5.3.8.tx20)
- prioritni projekty (NOVE v 5.3.8.tx20)
- moznost pouziti sitovych masek v remote_hosts.cfg (NOVE v 5.3.8.tx20)
- reset dluhu (NOVE v 5.3.8.tx20)
- opraven zakaz pristupu k siti (to ale nebyl muj bug, nybrz bug verze 5.3.6, z ktere jsem vychazel)

Reset dluhu bylo Honzovo prani (jeste jsem to ale netestoval, takze nevim, jestli to skutecne funguje

Prioritni projekty: BOINC bude spoustet jen zadany projekt (nebo projekty). Ostatni zaregistrovane projekty spusti jen jako backup v pripade, ze uz pro prioritni neni zadna prace a nove jednotky nejdou zrovna stahnout. Uplne to bude ignorovat jakekoli dluhy a jina nastaveni (samozrejme krome stopnuti nebo zakazu downloadu)

Takze vesele ale opatrne testujte, a kdyz narazite na problemy, dejte vedet. Taky by me zajimalo jestli funguje ten reset dluhu. Kalibrace kreditu se zacne projevovat postupne a pomerne pomalu - potrebujete spocitat peknych par jednotek, nez to bude OK. V Boinc manageru ani v BoincView korigovane kredity neuvidite. Az teprve na webu je to videt. Anebo v hlaskach a log souborech. Ta kalibrace je tak trochu s krizkem po funuse, ale co se da delat Ono se to ale na Enhaced taky jeste muze jednou hodit.

PS: zatim to nikam moc nesirte, na S@H to jeste davat nebudu. Pro pripad nejakych hrubych chyb, bych to radeji mel pod jakouz-takouz kontrolou. Crunch3r to tady sice asi odchyti, ale protoze se ted hlavne zajima o Enhanced, tak ho to mozna an nebude zajimat. Kazdopadne on to snad nikomu nevybulikuje.