Proè SETI nepakuje?

[Honza]

Nepamatuje si nekdo, zda-li se na SETI neuvazovalo o tom, ze by se WU pakovaly?
Jednoduchym zazipovanim (ci gzipem) se WU stlaci na 75% puvodni velikost, cim by se usetrila 1/4 (i) mista na disku SETI serveru, (ii) 1/4 trafiku z SETI, (iii) 1/4 trafiku vsem userum na download (a ze to neni malo), (iv) 1/4 mista na disku useru SETI. Je rozdil, jestli mi jedna masina stahne ze mesic 1GB nebo 750MB dat ze SETI.

Pouze je treba pri generovani WU data pakovat, ale normalni masina jich zapakuje (i s verifikaci) zhruba 15 za vterinu, tudiz trebas 50k za hodinu, coz odpovida rychlosti generovani novych WU na SETI.
Dale by bylo treba drobnych uprav aplicake, ktera by ti so pred analyzou rozbalila.
Proste aby <data length=365391 encoding="x-setiathome"> mel encoding gpiz nebo tak.

Tento napad zustava aktualni i po uvedenei SETI Enhanced, protoze tam se analyzuji stejna data. Proste jenom dalsi zpusob, jak udelat SETI trochu efektivni.

[trux]

Nepamatuje si nekdo, zda-li se na SETI neuvazovalo o tom, ze by se WU pakovaly?

Rozhodne je to v BOINC jadru pripraveno - zip knihovny jsou tam. Sam nechapu proc uz to davno nezipuji, a to ani ne tak s ohledem na misto na disku, ale predevsim kvuli prenosovemu pasmu - ta zatez prenosovych linek jde casto az k maximu, kdy na serveru zacinaji vypadavat pakety a tim se to zacykli a jde pomaleji a pomaleji, dokud tomu rucne nepomohou. Kdyby zipovanim badwidth zmensili na ctvrtinu, urcite by to bodlo. Jediny pochopitelny duvod pro to, ze to nezipujoou je, ze se skutecne obavaji, ze by komprimace/dekomprimace zatizila servery tak, ze by prestaly stihat svoji normalni praci.

[Honza]

Diky truxi - je to proste tak snadne, az je nepochopitelne, ze to nedelaji.
Jak jsem psal - obycejny desktop zvladne v realnem case pakovat stejne rychle, jako na SETI porcuji ten sum.
Argument, ze by to nestihaly servery, je zalostne pokulhavajici (chapu, ze to neni tvuj argument): nestihaji mimo jine prave proto, ze musi operavat s o 1/3 vetsim obejemem dat
Nepamatujes (nebo nekdo jiny), jestli se o tom neuvazovalo?

David Anderson docela kladl duraz na "datovy" aspekt jak SETI (drahe skladovani dat), tak BOINC (nevyuzity potencial pro skladovani dat). Pakovani jde ruku v ruce.

[FordPrefect]

Ano, vsechny kompresni metody s vyjimkou opakovaci metody jsou casove narocne. A opakovaci metoda je zase pro takovato data nepouzitelna.

[trux]

Jak jsem psal, uvazovalo se o tom zcela urcite, protoze jinak by ty zip knihovny vubec do BOINC jadra a serveru nezabudovavali.

[FordPrefect]

2 trux: je mi to jasne. Ke stejnemu zaveru jsem dosel, kdyz jsem koukal do zdrojaku boincu hned na zacatku. Take jsem si polozil otazku, proc posilana data nekomprimuji. A myslim, ze v berkeley udelaly spravne rozhodnuti. Obavy ze zateze systemu byly opravnene.

[trux]

To byla odpoved na Honzovu otazku "Nepamatujes (nebo nekdo jiny), jestli se o tom neuvazovalo? "

[FordPrefect]

To byla odpoved na Honzovu otazku "Nepamatujes (nebo nekdo jiny), jestli se o tom neuvazovalo? "

Ja jen, ze jsi na na to odpovedel dvakrat

[trux]

Ja jen, ze jsi na na to odpovedel dvakrat

No, kdyz se dvakrat zeptal, tak jsme dvakrat odpovedel.

[Honza]

Koukam, ze tema vybudilo nejaky zajem, takze jsem to odstrihnul od puvodniho.

@ FordPrefect. Podle ceho soudis, ze se rozhodli spravne?
Krome toho, ze jsem si to zmeril - a zjistil, ze normalni desktop to staci pakovat v realnem case! - mam jeste jeden dost padny argument, ktery ukazuje na fusarinu SETI projektu z hlediska efektivni (ne)vyuziti jejich i naseho trafiku:
Nova SETI aplikace - ktera ma problemy jeste pred jejim vydanim (viz problem s batter_banner, nemoznosti stahnout aplikaci a vubec laidactvi), ma s fftw3.dll knihovnou 2.7MB. Zapakovana ma 1.13 na beznou ZIP kompresy. Nova verze aplikace se bude distribuovat na desetitisice az statisice pocitacu (viz clanek The Computational and Storage Potential of Volunteer Computing, na ktery jsem upozornoval). To predstavuje pres 1.5MB usetreneho trafiku na strane UCB i uzivatele za kazdou soucasnou masinu (ktera bude nucena se strany SETI prejit na novou aplikaci), nove pripojenou masinu, zresetovanou masinu, znovupripojenou masinu do SETI, nove nainstalovanym BOICem atp. Nasobit kazdy umi, takze pocet usetrenych GB ci kazdy spocita. Znovu si to vynasobte pri kazde novejsi verzi aplikace.

Muzu lacine argumentovat tim, ze CPDN to takto dela jiz dlouho - a setri tim minimanle polovinu traffiku na downloadu CPDN. Pakuje aplikaci, pakuje data WU na download, pakuje uploady: proste efektivni vyuziti trafiku pomoci jednoducheho zipovani.
Jenze to neni nic vyjimecneho - aplikaci pakuje i primitivni a maly projekt BURP, ktery dela jeden clovek (kdyz to zvladne jeden clovek, snad by se to na SETI take mohlo podarit). gzip na data - bohuzel ne aplikaci - pouziva i Rosetta. Einstein by na aplikaci usetril jeste vice, kdyby pakoval - misto 4.1 MB 1.3 MB je dost rozdil;alespon maji optimalizovana data zasilana k analyze.
SETI nepakuje ani data, ani aplikaci, takze z tohoto hlediska vychazi nejhure. A to v momente, kdy ma nejvyssi traffic na masinu pri pocitani (pres 1GB mesicne na solidni masine).

Tezko rikat, ze na SETI take maji primo 'zodpovednost' za vyuzivani zdroju, ktere jim poskytujeme...ale byl bych rad, kdyby nejake veci trochu dotahli (let vyvoje na to meli dost) a zacali pouzivat BOINC a nase zdroje trochu efektivneji. Zvlaste tehdy, je-li to jiz pripravene, jak trux i ty tvrdite
Proste nemam dobry pocit z toho, ze bezi x let stara aplikace (ktera muze snadno bezet o dost rychleji) a efektivne neni evidentne vyuzito ani naseho pripojeni k netu nebo misto na disku.
Tak se mi to alespon ted jevi.

[trux]

Myslim, ze hlavni duvod je vytizeni serveru - ty bezi prakticky porad pod 100% zatezi, takze i kdyz tobe pakovani na desktopu bezi v real time, je uplne neco jineho, kdyz se jich ma pakovat a de-pakovat nekolik set za minutu. Taky v tom kulha srovnani s CPDN, ktery posila o nekolik radu mene jednotek, ale zato hodne dlouhych, takze situace je uplne jina. Nemyslim si, ze by to bylo lajdactvi ze strany S@H - nakonec to byli ti sami vyvojari, co v BOINCu to pakovani zabudovali jak v klientu, tak na serveru. Takze pokud se rozhodli nepouzit ho u S@H, asi pro to nejake duvody meli. Pocitam, ze s delsim vypocetnim casem u S@H Enhanced se situace zmeni, a pocitam, ze diky mensi zatezi serveru pakovani pozdeji pouzito moci bude. Co se tyce knihoven S@H Enhanced - to je stale jen beta projekt, neni tedy divu, ze detaily nejsou dotazene. Myslim, ze prozatim resi dulezitejsi veci a nepocitam, ze by to takto zustalo. Samozrejme se mohu plest, ale hazet hnojem ted, povazuji za predcasne.

[Honza]

truxi, argumenty jsou castecne pouzitelne pouze na (ne)pakovani dat k analyze (WUs). Ale jiz od zacatku mohlo byt pakovani pouzito na aplikaci a jeji knihovny (jako to dela CPDN, Burp) - tam je nejake vytizeni serveru nehraje roli, jelikoz aplikace se sestavuje jedno za xxx dni. Ale stahuje se nekolik-tisickrat kazdy den!
Mohlo to byt pouzito od zacatku nebo alespon pri prechodu lidi ze zombika - kdy byly servery pretizene mj. take tim, ze se tahala nepakovana aplikace.

Verim, ze nova aplikace bude casem distribuovana zapakovana (u Bety to opravdu neni treba a jsou tam dulezitejsi jine veci). Mozna treba premysli nad tim, ze budou aplikaci distribuovat zapakovanou a tudiz se neobtezuji napravit soucasny stav. Ale alespon by o tom mohli na foru informovat.

Chtel jsem se podivat na SETI forum, jestli tam o tom neco nenajdu...a opet je down

[dejvidek]

Taky v tom kulha srovnani s CPDN, ktery posila o nekolik radu mene jednotek, ale zato hodne dlouhych, takze situace je uplne jina.

Není tedy na čase přemýšlet o delších jednotkách i v SETI? Jednotky se koncipovaly, aby jejich zpracování netrvalo neúměrně dlouho, ale to bylo před 7-8 lety. Dneska jsou počítače i net na jiné úrovni a pokud by byla jednotka 3x větší a zabalená, dostanem se na +/- stejnou velikost.
Ale chápu, že by to bylo strašně moc práce, ale s přechodem na BOINC se nad tím mohlo makat
dejv

[Honza]

Ja myslim, ze WUs budou pro 'enhanced' verzi dost dlouhe - po 8.5 hodinach jsem nekde v 25% a tom mam tak zhruba stredna narocnou jednotku.
Premyslet a hlavne neco delat by se podle me melo s kompresi aplikace a mozna i jednotek.

[fatbozz]

Kdo je pro kompresní formát 7zip ať zvedne tlapku !