KREDIT, KREDIT, KREDIT... :)

[Honza]

Pokud se nepletu, tak u SETI se pøistoupilo k validaci hlavnì z toho dùvodu, ž nìkteøí chytráci v classikovi podvádìli. S validací je to nemožný. U CPDN by nejspíš podvádìt taky moc nešlo, ale co na tohle Rosseta? Jak tam je zabránìno podvodùm?

Myslim ze David psal, ze lze takove lidi odhalit a primo vyloucit (neco jako ban pres IP adresu). Je jasne, ze ma-li nekdo 1 masinu, nemuze spocitat 100 WU za den...proste selsky rozum to odhali.
Odhalit to samosebou mohou i bezni uzivatele, protoze v tabulkach podle RAC bude trcet a lide na nej mohou ve foru upozornit...protoze kazdy s accoutem je automaticky identifikovatelny minimalne pres UserID. Takto se preci objevila zvedavost jako to dela ten manik s testovacima Opteronama a kdyz vysvetlil svou pozici akceptovatelnym zpusobem, je to OK.
U CPDN by bylo HODNE tezke podvadet kvuli tricklum a jinym prubezne zasilanym vysledkum - ani si nedokazi predstavit, jak by to byl nekdo schopen delat. Vysledky jsou totiz dobre srovnatelne s paramtry jinych modelu (napriklad aproximaci) a tudiz snadno odhalitelne.

Myslim, ze co se tyce kreditu, muze fungovat i jako indikator kontroly.

[FordPrefect]

No, staci pocitat WU a pridelovat si nekolikanasobne vyssi kredit. Blokovani pomoci IP taky neni nejrozumejsi. Myslim, ze ta validace je velmi rozumna, protoze eliminuje vadne vysledky( at uz z duvodu podvodu nebo chyby ve vypoctu ). A o kvalitu vysledku jde ve vedeckych projektech predevsim

[Honza]

No, staci pocitat WU a pridelovat si nekolikanasobne vyssi kredit.

A jak si jako ten zatraceny kredit budes pridelovat?

Myslim, ze ta validace je velmi rozumna, protoze eliminuje vadne vysledky( at uz z duvodu podvodu nebo chyby ve vypoctu ). A o kvalitu vysledku jde ve vedeckych projektech predevsim

Otazka stale je, kolik vysledku je treba duplicitne pocitat, aby byly validni. Pro nekoho pocitat vsechno 4-5x je zbytecne mrhani. Samosebou zalezi projekt od projektu a proto je quorum nastavitelne...

[Miras]

Myslím že když někdo bude chtít podvádět, cestu si vždycky najde. Nejsou statistiky jen celkový, ale třeba i týmový, jako máme my. Když chce někdo vyniknout ve statistikách týmovejch, nemusí to nutně znamenat že nějak vyčnívá ze statistik světovejch. Navíc v dnešní době se nechá falšovat skoro všechno. Je třeba možný pustit benchmark na jednom compu, počítat na druhým. Zdrojáky sou volně přístupný, kdyby si s tím někdo dal práci, může si klienta i aplikaci upravit k obrazu svýmu.
Říkáš že v CPDN podvádět nelze, vymlouvat ti to nebudu, sám bych byl nerad kdyby tě někdo přesvědčil o opaku. Prvotní otázka zněla, jakej obrannej mechanismus proti podvodům má Rosetta? Nevím kolik userů Rosetta má, ale každopádně každýho manuálně kontrolovat, jestli výkony odpovídají nasazený výpočetní technice je nemožný. A jestli podvodníka nalezne některejch z uživatelů je otázka náhody. Počítače se nechají skrýt, RAC mi neřekne vůbec nic.
Zkrátka si myslím že validace určitě smysl má. Dvě jednotky pro validaci nestačí, aby se mohlo mluvit o většině, musejí být tři. Znáte lidi, čekají na kredit tejden a už sou nervózní, myslím že čtyři jednotky u SETI sou tak akorát. Pro validaci stačí tři, ale když jeden výsledek nezvaliduje, musí se jednotka stejně posílat čtvrtýmu a zas se čeká na kredit. Jednak to zvyšuje zátěž serveru, páč na zvalidování čeká víc jednotek, jednak sou lidi nervézní, co to že ještě nedostali kredit. SETI počítají spousty lidí, takže si můžou (bohužel) i nějaký to mrhání výpočetním potenciálem dovolit. U jinejch projektů, kde těch lidí tolik není, musí prostředky využívat maximálně efektivně, za cenu vyšších rizik (čas do přidělení kreditu, podvody,...)

[Honza]

Zatim nevim o pripadu, ze by nekdo pod BONICkem podvadel. Vite o nekom?
Netvrdil jsem, ze [v CPDN] podvadet nelze, ale ze si nedokazi predstavit, ze by to nebylo odhaleno...a popravde nejsem schopen vymyslet na CPDN mechanizmus, jak by se to dalo realizovat. VI nekdo jak na to? Please, PM/SZ
Neni vubec treba skryvat masiny a tim schovavat RAC. Server preci vidi vsechny masiny a udelat script, resp. doplnil do updatu statistiky nejakou kontrolu extremu a ty dat stranou a juknout na ne neni problem. Kdyz se dela hloubkova analyza vysledku, proc by se nemohla delat povrchni analyza masin? Napriklad vedet o masinach, ktere posilaji vetsi procento spatnych vysledku...coz se vlastne dela, protoze se jim snizuje daily quota. Staci to jenom trochu domyslet a zrealizovat.
Problem validizace pri mensim poctu redundantnich vypoctu a pritom be dlouheho necekani na kredit se da elegantne resit tim, ze kdyz po nejake dobe nedojde 3. vysledek (nebo je s chybou), zaradi se takove jednotky tem hostum, kteri maji kratky turnaroun a maly buffer -> masiny, ktere jsou rychle a vysledky ryhcle vraceji (nemaji velky buffer). Je dost masin, ktere vraceji vysledky do par hodin. Vzdyt to preci BOINC umi (udaje v db pro to jsou), tak proc nedat dva paramtry vedle sebe

[FordPrefect]

Ja narazel na to, ze rosetta neprovadi porovnani spocitane WU s jinymi uzivateli. Staci mi tedy upravit boinc clienta, aby z nej vypadavali vysoke benchmarky a kreditu bude hodne

[mb]

Čtu tuto diskusi o přidělování kreditu a falšování výsledků zpracovaných WU. Nějak mi hlava nebere smysl těchto praktik.
Dosud jsme měl pocit, že účelem těchto projektů je pomoci hledání řešení civilizačních problémů, a nikoliv sbírání kreditů. Přičemž připouštím, že soutěživost (tj. sbírání kreditů) pomáhá zapojit větší množství lidí. Nicméně dopouštět se falšování výsledků a tím znehodnocování výzkumných projektů je minimálně k hlubokému zamyšlení.

Myslím si, že takoví lidé by se měli nad sebou zamyslet!

[forest]

Nemohu jinak, než souhlasit, ale bohužel se vždy najde někdo kdo má jiné preference a kvůli takovým se na většině projektů počítá stejná WU na vícero počítačích.

[Honza]

Podvadeni je beznou praktickou o SETI/classic a-la zombie.

Stale nevim o pripadu, ze by nekdo 'falsoval' vysledky pod BOINCem a je to pro mne pouze na hypoteticke rovine.
Ze se nekdo honi za kredite...vsak to je jenom takove pozlatko, ktere validitu vysledku nijak nesnizuje.

[Honza]

OK, tedy zpet ke kreditu...jelikoz s falsovanim vysledku (tim myslim ResultID; kredit neni zadny vysledek ale stejne prazne nic jako ego ). Samosebou jsou zpusoby, tak ovlivnivat kredit. Trebas udelat si vlastni kompilaci BOINC, kde se zakaze automaticky benchmark po 5 dnech a rucni zmena client_state.xml atp.

Cetl jsem zajimavou diskusi na Rosette i Einsteinovi a par dalsich veci a zkousel vlastni uvahy. Je jasne, ze soucasny system pridelovani kreditu je ne zrovna vyhovujici (a ani David Anderson mne osobne nepresvedcil pred 2 lety o opaku)...samosebou to neplati pro CPDN, kde nejaky benchmark a jeho manipulace sumak. OK, dost (sebe)chvaleni.

Reseni se nabizi vic, napriklad to, ktere navrhl Paul D. Buck. Koncept zalozeny na 'kalibraci'.
Je to dost propracovany system, ktery nejsem schopen nejak snadno uvest, protoze ma hned nekolik urovni.
Hrube zjednoduseno se da rici, ze kazda masina by byla kalibrovana nejakymi kalibracnimi jednotkamy (cimz se da i testovat stabilita systemu atp.). Samosebou je zde problem prenositelnosti na jiny pocitac, nebo zmena HW ci SW v tom samem pocitaci, ktera muze jeho vykon ovlivnit. Jiste, nic neni dokonale...

Zatim se mi stale zda jako smysluplna ona kontrola extremu vuci prumeru.

Jaka vas napadaji reseni problemu? Nedostatky soucasneho stavu jsou celkem zname (alespon angazovanym), ale co reseni...?

[trux]

Reseni se nabizi vic, napriklad to, ktere navrhl Paul D. Buck. Koncept zalozeny na 'kalibraci'.

Kalibrace rozhodne neni navrhem Paula. Sam jsem ji navrhoval jiz davno predtim v nekolika threadech (napr. tady: http://setiathome.berkeley.edu/forum_th ... p?id=15996), ale dost pochybuju o tom, ze jsem byl prvnim koho to napadlo. Myslim, ze to bylo v umyslu vyvojaru BOINCu od zacatku, akorat to proste jeste nestihli dotahnout.

Jinak, konstantni kredit za jednotky proste u vetsiny projektu neni mozny, protoze jednotky se mohou casovou i vypocetni narocnosti diametralne lisit.

Jinak i soucasny stav neni az tak hrozny - protoze kredit se prideluje podle stredniho kreditu z prvnich tri doslych vysledku (alespon u S@H), i kdyz nektere pocitace vyzaduji diametralne jine kredity, v prumeru se to celkem srovna. Kdyby byly klienti kalibrovani, procento nepresnosti by se podstatne omezilo. Co se tyce kalibracnich jednotek a pripadne manipulace s jejich presmerovavanim na rychlejsi masiny - tak na to je nejlepe zkombinovat nekolik mechanismu - napr. pouziti MD5 hashe vysedku dohromady s nekterymi parametry systemu, ktere zaruci se se stale jedna o stejny pocitac (v opacnem pripade se kredit bude znova kalibrovat, nebo oznaci jako men spolehlivy a vylouci z prumerovani). Toto by se stale dalo obejit pouzitim upraveneho klienta, a proto by kalibracni jedntoky musely chodit nahodne a alespon nektere z nich byt nerozlisitlene od normalnich jednotek, aby se zamezilo tomu, ze je uzivatel odchyti a presmeruje.

[forest]

Spíše by mě zajímalo, jestli už se vůbec nějaký podvodní skutečně odhalil, nebo jestli je vše jenom teorie, že by někdo něco mohl?
Teortická možnost podvodu je věc jedna, ale skutek že k podvodům skutečně dochází, je věc jiná.

Nerad bych vzbuzoval u nových návštěvníků fóra totiž hned dojem, že BOINC je systém kde je podvádění na denním pořádku

[Blackhat]

Je to smutny, ze se o tom vubec musite bavit. Kde je nejaka hrdost a cest a koukani do zrcadla :(

[Honza]

Asi jsem spatne pochopil, ze to navrhl Paul...ale minimalne se tim zabyva a angazuje se v tom.
Vim, ze konstatni kredit za WU neni mozny a ze je to pouzitelne pro CPDN a pripadne dalsi projekty, kde se narocnost WU moc nemeni (napriklad louskani sifer ci jine matematicke ulohy).

Problem je spatrovan v souvislosti s Rosettou. Tam jsou toho nazoru, ze duplicitni vypocty jsou mrhanim casu (i ja si myslim, ze 4 vypocty jsou zbytecne). Pominu to, ze napriklad Paul si mysli, ze SETI je vubec 'junk science' a tudiz uplne mrhani vykonu, ale to je jeho vec.


Me by se zamlouval vice hierarchizovany model pridelovani kreditu. Kalibrovaly by se masiny tim zpusobem, ze se bude prumerovat vysledek vypoctu na danem typu OS a CPU. Napriklad se bude vedet, ze AMD X2 dela jednotky v prumeru za 60 minut (mereni muze byt snadno stovky ci tisice behem alfa/beta testu). Kdyz budu mit X2, staci vynasobit nasobkem casu, ktery jsem na to stravil * frekvence CPU.
Na lokalni masine by nebezel zadny benchmark a pridelovalo by se to z database na serveru (ta by mohla byt prubezne aktualizovana napriklad pri aktualizaci statistiky). Eliminuje se tim misto pro manipulaci - napriklad za predpokladu, ze BOINC pri startu kontroluje typ CPU. Pokud dojde ke zmen, je to sumak...protoze se pri odesilani vysledku reportuje i typ/frekvence CPU. Beru namitku,ze i dalsi komponenty maji vliv, ale nejsou to radove desitky procent ci dokonce nasobky (jako jsou momentalne rozdily narokovaneho kreditu), ale pouze procenta.
Resi to i problem toho, ze benchmark je nic-nerikaji cislo, ktere nema vysokou korelaci s danym CPU, pocitanym projektem.
Myslim, ze by to i resilo 'inflaci' v momente, kdy by byl plosne nasazen optimalizovany klient (e.g. novejsi verze aplikace), takze by to neznevyhodnovalo ostatni projekty, jak se deje v soucasnosti.
Co treba takovyto scenar?

btw, proc nebyla akceptovana zadna z navrhovanych zmen? Je to prilis prace to implementovat?

[forest]

Porovnávání je sice hezké, ale co třeba v mém případě, když z mého Prescotta vyždímu o polovinu větší výkon než kdyby jel na default a paměti taky? To bych byl hned označen za podvodníka?