Kreditní systémy BOINC

[LiborA]

"Poprask" kolem kreditního systému projektu TANPAKU v uplynulých mne přivedl k zamyšlení, který systém přidělování kreditu považuji za nejvhodnější. Protože si myslím, že každý z nás má to nějaký názor, rozhodl jsem se nakonec založit toto vlákno k diskusi na problematikou kreditů za výpočet.

A nyní k mému (současnému) náhledu na tuto problematiku. Po zkušennostech s provozováním OS Windows a Linux na jedné mašině a přidělování drasticky rozdílného kreditu za jednotku času v rámci jednoho projektu pod těmito různými OS jsem již před časem zavrhl systém založený na banchmarku. Velmi se mi líbí systém E@H a CPDN, kdy dostávám za jednotku víceméně jasné množství kreditu.

Když jsem se v uplynulých minutách zamyslel na systémem zavedeným TANPAKU, tak musím říct, že se mi začíná líbit čím dál víc - až na množství kreditu, které přidělovali (už toho tolik nepřidělují, takže vy kdož se honíte jen za kreditem - bonanza již je uzavřena). V čem spočívá kouzlo kreditního systému, který používal TAPAKU? Dostával se kredit za čas strávený na výpočtu a byl přidělován podle času prvního odevzdaného výsledku. Bohužel TANPAKU nastavilo nesmyslných 36 kreditů za hodinu, za optimální bych považoval např. 10 kr/h. První kdo odevzdá výsledek dostane svých X kreditů za hodinu výpočtu a další odevzdané výsledky dostanou stejné množství kreditu, tj. jejich průměrný kredit za hodinu bude závislý na poměru délky výpočtu mezi jejich PC a PC prvního výsledku. Zde ovšem spočívají i určité "slabiny" tohoto systému. To první slabinou je v konečném důsledku možnost přidělení naprosto rozdílného kreditu za výpočtově shodně náročné jednotky - což by bylo po právu kritizováno. To na druhé straně ovšem může vést i k tomu, že někdo s výkonným PC bude dostávat za hodinu stejné množství kreditu jako člověk s podstatně pomalejším PC - i když to nebude pravidlem, tak chápu, že to není nejférovější princip. Na druhou stranu strávili oba na výpočtu stejný čas takže v tom by zase určitá férovost byla.
Další "slabinou" je i určitá možnost "zneužívání" - pokud budu mít velmi výkonný počítač, bude pro mne výhodnější si nastavit BOINC tak, abych neodevzdával výsledky jako první a tím pádem ve většině případů dostanu hodinově více kreditu - ale to ostatně nepovažuji za chybu.

Uf, to jsem se zase jednou rozepsal

[FordPrefect]

System pridelovani kreditu podle benchmarku je obecne spravny. Je ale s podivem, ze je udelan pomerne spatne. Kdyz na stejnem pocitaci za skoro stejnych podminek vypadavaji z nej uplne jina cisla, tak to asi maji spatne udelane. Chapu, ze nikdy to nebude uplne stejne, ale z toho benchmarku by mela vypadavat cisla +-10%

[Honza]

Myslim, ze je dulezite mit na pameti hlavni myslenku kreditu - ukazatel odvedene prace, ktery bude srovnatelny mezi projekty.

Souhlasim s Fordem ohledne podobne tolerance.
K syntetickym testum jsem byl vzdy skepticky a nejake testy propustnosti pameti, kterymi se tady nekdo vychloubal, nejsou moc vypovidajici o realnem vykonu.

Jednoduchy benchmark sel nahradit systemem kalibracnich jednotek a testem stability masiny - to me sveho casu oslovovalo. Ted uz se to asi prosralo a je pozde neco takoveho zavadet...skoda. Predpokladam take, ze kalibracni jednotky by prave tu toleranci 10% mezi ruznymi OS a nasledne i mezi ruznymi projekty zajistily.

Stale si nejsem jist, ze zavrhnuti myslenky centralniho serveru (ktery by byl po instalaci standarniho BOINCu kontaktovan, stahl by kalibracni jednotku/y a pridelil masine CPID) bylo zcela prozretelne. Nektere projekty by mozna radsi davaly vypocty kalibrovanym ci jinak otestovanym masinam, nez to x krat rozesilat smesce ne moc stabilnich pocitacu.

Obecne je mi blizky zpusob pridelovani kreditu, ktery na pocatku zavedl CPDN. Ma vsak slabinu v tom, ze aplikace pod ruzne OS nemusi byt stejne rychla nebo muze "nadrzovat" tomu ci onomu CPU. Pokud je to tech +- 10%, tak je to v norme.
Zasadni vyhodu proti benchmarku to vsak ma v tom, ze to nelze sidit - tudiz to eliminuje podvodniky ci lidi pouzivajici optimalizovane clienty.

Zustava zde otazka optimalizovanych aplikaci. Na jednu stranu to respektuje zasadu odmenovani podle vykonanen prace, na druhou stranu to porusuje paritu mezi projekty Precedenc SETI, ktery timto nejvice znehodnotil paritu mezi projekty, je stale zivy.
Mozna, ze kalibrace v klientovi se na toto uspesne zameruje, ale jelikoz neni soucasti standardniho BOINC, problem ve vetsine pripadu stejne nijak neresi...a kdyz si to pusti amater na projektu s quorem 1...no to uz vime.

Pokud to lze, davam prednost pridelovani kreditu na strane serveru - podle vzoru CPDN a pozdeji Einsteina, coz resi moment ruznych verzi a optimalizaci BOINCu a cini kalibraci zbytecnou. Navic vychazi z ukazatele odvedene prace a ne vysledku jakychsi testu, ktere nejsou ani moc reliabilni, ani moc validni.