nazdar,
chcel by som sa spytat, ci má doba za ktoru spocitam WU vplyv na výsku kreditu...
viem ze napr. pri rosette je dost casto velky rozdiel medzi claimed a granted kredit...
pytam sa hlavne preto lebo na notebooku nemam vzdy internet, pripajam sa asi iba raz za dva dni cez tyzden...
diki
Kreditový systém
Moderátor: Moderátori
-
Kiwi
- Príspevky: 2072
- Dátum registrácie: Ut Feb 13, 2007 4:18 pm
- Bydlisko: Sobrance
- Kontaktovať používateľa:
Re: Kreditový systém
Co myslis pod: "doba, za ktoru pocitam WU" ? Ak ju spocitas za x sekund dostanes y bodov,
len ju musis odoslat do deadlinu. Ale aj ked ju odosles kratko po nom, tak ti ju zapocitaju.
Pomer medzi cranted a claimed kredit je rozny u kazdeho z projektov. Ak napr. v Cosmology
spocitas nejaku WU, to je jedno, ci za 3000 alebo 11000 sec. vzdy mas 100 bodov.
Ak napr. v QMC spocitas nejaku WU za 2000 bodov napr. za 109 000 sec. a iny ju spocita
za 150 000, tiez dostane 2000 bodov, ale credit per day mas napr. pri C2D 2 * 86400 / 109 000 * 2000
= 3171 ale pri dlhsom case mas kredit za den len : 2 * 86400 / 150 000 * 2000 = 2304 bodov.
len ju musis odoslat do deadlinu. Ale aj ked ju odosles kratko po nom, tak ti ju zapocitaju.
Pomer medzi cranted a claimed kredit je rozny u kazdeho z projektov. Ak napr. v Cosmology
spocitas nejaku WU, to je jedno, ci za 3000 alebo 11000 sec. vzdy mas 100 bodov.
Ak napr. v QMC spocitas nejaku WU za 2000 bodov napr. za 109 000 sec. a iny ju spocita
za 150 000, tiez dostane 2000 bodov, ale credit per day mas napr. pri C2D 2 * 86400 / 109 000 * 2000
= 3171 ale pri dlhsom case mas kredit za den len : 2 * 86400 / 150 000 * 2000 = 2304 bodov.
Re: Kreditový systém
no myslel som tým to, že či je rozdiel v kredite ak spocitam WU za 3 hodiny a hned vysledok odoslem, alebo ak vysledok poslem az napr o dva dni...
pochopil som to tak, ze zalezi na pribliznom case trvania výpoctu, aj ked je to u kazdej masiny relativne, a samozrejme je treba to stihnut do deadlinu.
uvediem priklad... 1 rosetta WU mi spočita priblizne za 3 hod. claimed credit sa pohybuje od 30-do 60../priblizne/... prizna mi server vyssi kredit ak vysledok odoslem ihned po vypocte, ako ked odoslem vysledok az o dva dni neskor?
a podla coho vlaste rosetta posudzuje kredit? granted mam niekedy nizsi, niekedy vyssi ako claimed a neviem na com to zalezi...
pochopil som to tak, ze zalezi na pribliznom case trvania výpoctu, aj ked je to u kazdej masiny relativne, a samozrejme je treba to stihnut do deadlinu.
uvediem priklad... 1 rosetta WU mi spočita priblizne za 3 hod. claimed credit sa pohybuje od 30-do 60../priblizne/... prizna mi server vyssi kredit ak vysledok odoslem ihned po vypocte, ako ked odoslem vysledok az o dva dni neskor?
a podla coho vlaste rosetta posudzuje kredit? granted mam niekedy nizsi, niekedy vyssi ako claimed a neviem na com to zalezi...
Re: Kreditový systém
O kreditovem systemu byl uz napsany i clanek, jestli se pamatuji...tusim trxu se na nem nejvice podilel.
BOINC obecne uziva dva pristupy kreditniho systemu - hodne zjednodusene.
Prvni vychazi ze syntetickych benchmarku - tedy takoveho umeleho testu, ktery meri potencionalni vykon v aplikacich. Narokovany kredit se pak pocitaji jako vyse tohoto benchmarku * cas vypoctu.
Podle mne lze zasadni nevyhody tohoto systemu vyjmenovat takto:
- synteticky test neodpovida realne aplikaci. Kazda aplikace vytezuje stroj jinak - benchmark se prilis soustredi na zakladni instrukce CPU. Existuji vsak aplikace lepe vyuzivajici moderni CPU formou rozsirenych sad instrukci SSE/2/3, intenzivne vyuzivajici pamet neb narocne na diskove operace.
- vysledek systnetickeho testu je zavysly na uzite platforme. Drive byly dlouhe diskuse kolem toho, ze na stejnem HW dava Win, Linux a MacOS rozdilny benchmark, coz bylo - opet umele a synteticky - dorovnavano. Navic 64-bit dava opet jine cislo nez 32-bit, optimalizovane BOINC core davaji opet jina cisla.
- temito vysledky lze manipulovat
Samotny projekt si muze zvolit metodu prideleni kreditu. Kuprikladu ze dvou narokovych kreditu v ramci WU se udelat prumer, ze 3 se vybere prostredni atp. Z toho vyplyva rozdil mezi claimed a granted.
Druhy zpusob pridelovani kreditu ignoruje sytenticke vysledky benchmarku a dava fixni (tj. predem stanoveny) kredit za vypocet urciteho typu jednotky. Zasadni vyhodou tohoto systemu je emilinace moznosti manipulovat s vysledky benchmarku. Zdanlive spravedlivy system narazi na jeden neprekonatelny problem: nasazeni je mozne pouze tam, kde lze delku/narocnost vypoctu predem urcit (CPDN) nebo alespon ovlivnit preferenci delky vypoctu (Rosetta, RCN). Nektere projekty maji typ vypoctu akovy, ze predem nelze u zadne WU urcit jeji narocnost a navic je nelze rozdelit typologicky (jmenujme BURP).
Kompromisem je projet par jednotek na typickych strojich a kategorizovat narocnosti. Neni to zcela presne, ale je to stale dobry odhad.
(claimed credit je spise orientacni udaj).
Existuji i sofistikovanejsi a spravedlivejsi systemy...bohuzel jen teoreticky. Trux sveho casu propagoval system kalibraci: testovaci jednotka ve forme aplikace emuluji typicky vypoctove ulohy se pusti jako prvni po instlaci BOINCu. Sterilni benchmark se nahradi realnejsim testem, ktery se vice blizi opravdovemu nasazeni. Vyhodou je, ze vysledek lze porovnat a z nej urcit "kvalitu" vypoctu. Pokud nekdo nesetrne overclockuje, ma nekvalitni HW nebo jinym zpusobem nestabilni masinu, je mozne to odhalit predtim, nez pokazi x vysledku na zivych projektech. "Znamkovanim" masin by mohlo byt zaruceno, ze vysledky budou realiabilni a validni. Ve finale je mozne redukovat replikaci vypoctu na samotnych projektech. Projekty by pak pocitaly efektivneji a kvalitneji zaroven. (kalibrace je mozne po urcite dobe opakovat obdobnym zpusobem, jakym se standardne opakuji benchmarky).
V soucasne dobe (tj. opet je jedna z vln) se mezi developery diskutuje o kreditovem systemu.
Mezi zasadnejsi otazky patri, zda-li ma urcita masina dostavat stale stejny kredit (tj. 100 za den i po 5 letech), nebo jestli ma dostavat prumerna masina proste 100 za den v libovolne dobe.
BOINC obecne uziva dva pristupy kreditniho systemu - hodne zjednodusene.
Prvni vychazi ze syntetickych benchmarku - tedy takoveho umeleho testu, ktery meri potencionalni vykon v aplikacich. Narokovany kredit se pak pocitaji jako vyse tohoto benchmarku * cas vypoctu.
Podle mne lze zasadni nevyhody tohoto systemu vyjmenovat takto:
- synteticky test neodpovida realne aplikaci. Kazda aplikace vytezuje stroj jinak - benchmark se prilis soustredi na zakladni instrukce CPU. Existuji vsak aplikace lepe vyuzivajici moderni CPU formou rozsirenych sad instrukci SSE/2/3, intenzivne vyuzivajici pamet neb narocne na diskove operace.
- vysledek systnetickeho testu je zavysly na uzite platforme. Drive byly dlouhe diskuse kolem toho, ze na stejnem HW dava Win, Linux a MacOS rozdilny benchmark, coz bylo - opet umele a synteticky - dorovnavano. Navic 64-bit dava opet jine cislo nez 32-bit, optimalizovane BOINC core davaji opet jina cisla.
- temito vysledky lze manipulovat
Samotny projekt si muze zvolit metodu prideleni kreditu. Kuprikladu ze dvou narokovych kreditu v ramci WU se udelat prumer, ze 3 se vybere prostredni atp. Z toho vyplyva rozdil mezi claimed a granted.
Druhy zpusob pridelovani kreditu ignoruje sytenticke vysledky benchmarku a dava fixni (tj. predem stanoveny) kredit za vypocet urciteho typu jednotky. Zasadni vyhodou tohoto systemu je emilinace moznosti manipulovat s vysledky benchmarku. Zdanlive spravedlivy system narazi na jeden neprekonatelny problem: nasazeni je mozne pouze tam, kde lze delku/narocnost vypoctu predem urcit (CPDN) nebo alespon ovlivnit preferenci delky vypoctu (Rosetta, RCN). Nektere projekty maji typ vypoctu akovy, ze predem nelze u zadne WU urcit jeji narocnost a navic je nelze rozdelit typologicky (jmenujme BURP).
Kompromisem je projet par jednotek na typickych strojich a kategorizovat narocnosti. Neni to zcela presne, ale je to stale dobry odhad.
(claimed credit je spise orientacni udaj).
Existuji i sofistikovanejsi a spravedlivejsi systemy...bohuzel jen teoreticky. Trux sveho casu propagoval system kalibraci: testovaci jednotka ve forme aplikace emuluji typicky vypoctove ulohy se pusti jako prvni po instlaci BOINCu. Sterilni benchmark se nahradi realnejsim testem, ktery se vice blizi opravdovemu nasazeni. Vyhodou je, ze vysledek lze porovnat a z nej urcit "kvalitu" vypoctu. Pokud nekdo nesetrne overclockuje, ma nekvalitni HW nebo jinym zpusobem nestabilni masinu, je mozne to odhalit predtim, nez pokazi x vysledku na zivych projektech. "Znamkovanim" masin by mohlo byt zaruceno, ze vysledky budou realiabilni a validni. Ve finale je mozne redukovat replikaci vypoctu na samotnych projektech. Projekty by pak pocitaly efektivneji a kvalitneji zaroven. (kalibrace je mozne po urcite dobe opakovat obdobnym zpusobem, jakym se standardne opakuji benchmarky).
V soucasne dobe (tj. opet je jedna z vln) se mezi developery diskutuje o kreditovem systemu.
Mezi zasadnejsi otazky patri, zda-li ma urcita masina dostavat stale stejny kredit (tj. 100 za den i po 5 letech), nebo jestli ma dostavat prumerna masina proste 100 za den v libovolne dobe.
