Optimalizovaná aplikace Einstein@Home I

[wampa]

Nevite nahodou jakeho klienta akosf pouziva (jakou optimalizaci)? kdyz se podivate
http://einstein.phys.uwm.edu/hosts_user ... rid=121407
tak si i pres optimalizace narokuje docela pekny kredit.

Podle výpisu v logu jednottek by to mněl být
<core_client_version>4.45</core_client_version>
Standartní oficiální BOINCmanager 4.45
Divné jsou výsledky benchmarků

XP1700- 14 630.21/ 7 334.96
opteron- 17 090.91/11 370.19
duron - 18 931.8/12 098.27
MP 1.86- 19 454.4/ 9 683.78
MP 1.8 - 9 410.01/5 174.03
ty vypadají jako od truxova klienta
Každopádně se mi nezdá, že by dohromady požadoval nějak moc.

Ten kredit mi pripada rozumny, jen mne prave zarazilo, jak se mohl dostat k takovym benchmarkum

[LiborA]

Je k dispozici nová verze U41.03 http://eclient.tvn.hu/alb_U4103.zip . A i první validovaný výsledek, takže je snad v pořádku

[Bijek]

Ten kredit mi pripada rozumny, jen mne prave zarazilo, jak se mohl dostat k takovym benchmarkum

Co takhle ruční úprava v client_state.xml

[azor666]

Co takhle ruční úprava v client_state.xml

Afkos na fóru už, poodhalil totožnost toho svého Opteronu

...Processor: Sempron E6 1600MHz (strongly believes he is Opteron 842)...

ROFL. Takže bych se nedivil ničemu.
[SPEKULACE]IMHO editovat ručně client_state.xml mi na Afkose přijde moc primitivní. Spíš bych typoval že zkouší nejakou vlastní verzi kalibrace/upravil si tu truxovu?
Nevím je stovka dalších možností. A všechno spekulace.[/SPEKULACE]

[Necroman]

Nove vysledky testovani optimalizovaneho Alberta - procesor: PentiumM Banias 1,5 GHz, 400MHz FSB
puvodni r_ 6:50 hodin
A36 - r_ 3:00 hodin
S37a - r_ 3:00 hodin, z_ 2:50 hodin
S38 - r_ 1:55 hodin, z_ 1:50 hodin
S39L - r_ 0:30 hodin, z_ 1:40 hodin (r_ nova, rychlejsi serie)
S41.06 - r_ 0:20 hodin, z_ 1:10 hodin
Zaver - porad je co zlepsovat

[Garbaty John]

U 41.03 - 35 minut 2,117 sekund

Tak mi to vychází rychlejší o 3 - 5 minut než S 41.06. Zatím spočtený první výsledek a je z validovaný.

Procesor Opteron 144 2079MHz.

[forest]

Mohu nabídnout další výsledek z AMD, tentokráte Bartona 2500@3200+
Před optimalizací 15042 s
s optimalizaci A36 6163 s
S39L - 4010 s
D 41.12 - 2730 s

To už je jen 18% původního času

[wampa]

D41 - jednotka mající 1432 cyklů - 43 minut!

Jinak právě jsem dosáhl kvóty 32 wu/den, takže mám ještě 5 a sucho...a minulej příspěvěk se tu ještě ani neohřál .

Je tu jedna moznost, ktera ale bouzel tobe nepomuze, ale pro ty co maji problem s kratkyma jednotkama existuje reseni.

Nastavit zasobu na vice dnu. Kdyz prijdou karatke jednotky, tak se pocita s tim co uz je stazeno (ty dny dopredu), a kdyz jsou dlouhe (kterych se nestihne 32 za den) tak se zase stahuje do zasoby. chvili to trva nez se ten buffer zasobi,ale jinak mne to funguje v pohode.

[Honza]

@ wampa - to opravdu neni reseni.
Kdokoli, kdo stahne cas pod 45 minut na WU, ma problem, i kdyby mu chodily pouze dlouhe WUs. (Ted mam cas s U verzi kolem 35 minut a jestli dneska nahodim lepsi pameti, tak to treba sleze jeste dolu )

"Nejjednnodussim" - nebo spise ctete neujistejsim - resenim je asi opravdu zmenit parametry masiny tak, aby si scheduler myslel, ze mam vic CPU nez ve skutecnosti mam. Proste misto 2 dat treba 3 nebo 4. btw, BOINCStudio to umoznuje pred GUI pro ty, kteri se nechteji prasit ruce rucnim editovanim xml souboru.
Docasne zvednuti poctu CPU razidi to, ze navrhuje wampa - ale nemusi se cekat dny, ale par minut (u SETI par hodin), protoze se kazdou minutu stahne x jednotek (u SETI se musi vzdy 10 minut cekat na dalsi RPC).

Dalsi zpusob, ktery mne napada - a ktery nedoporucuji! - by byla moznost prihlasit do projektu 2x pres ruzne URL (jako napriklad na CPDN http://www.climateprediction.net i climateprediction.net). Nedoporucuji to proto, ze verze BOINC 5.4.4 se zmenou libcurl knihovny prinesla takovym projektum problemy (CPDN main mel v podstate adresy). Zmenou serveroveho BOINC to udelalo bordel dalsim projektum - trebas BURP s tim ted zapasi.
Trochu standardnejsi moznosti je mit 2 BOINC instalace a jakmile je jedna na suchu, pustit druhou. Mozna by slo mit proste dve instalace a pouze se prepinat magorem...nevim, nezkousel jsem. To uz je lepsi reseni a hackovanim poctu CPU nebo to pustit pres VMWare.

Pak je jeste moznost se modlit, a to hned dvema zpusoby:
1. at konecne zvednou kvotu A ZAROVEN at to vydrzi servery Einsteina, o kterych si myslim, ze uz ted maji dost - podle toho, jak delaji mrtveho brouka.
2. at zacnou ve vetsi mire rozesilat 'j' a 'p' jednotky ci nejake jeste delsi.

[dash9]

Po pár testováních musím bohužel konstatovat, že na Prescottu 3,0GHz se zaplým HT je stále nejrychlejší S40.04, všechny novější verze byly pomalejší (z toho S41 a U41 o dost).

[Bubak]

2 Honza: Mas nejake blizsi info o "j2" a "p2" jednotkach? Co jsem louskal na E@H foru toho moc neni, krom toho, ze lidi nadavaj kvuli initial replication 6.
Skoro to vypada jako by se snazili zdrzovat S4 co nejdyl (to je mozna i duvodem nezvysovani kvoty). Ze by v priprave S5 nestihali?

[JardaM]

[quote="Honza1. at konecne zvednou kvotu A ZAROVEN at to vydrzi servery Einsteina, o kterych si myslim, ze uz ted maji dost - podle toho, jak delaji mrtveho brouka.
2. at zacnou ve vetsi mire rozesilat 'j' a 'p' jednotky ci nejake jeste delsi.[/quote]
2. Ještě jsem j a p WU neviděl.
1. Servery E@H asi trpí, ale neházej slinu, ještě nezklabovaly jako v Klimaktériu.

[Lesmen]

tak dalsi varka optimalizaci,tak se chlubte jak se vam zrychluje vypocet

[forest]

tak dalsi varka optimalizaci,tak se chlubte jak se vam zrychluje vypocet

Kterou várku myslíš?

[vejpuste]

tak dalsi varka optimalizaci,tak se chlubte jak se vam zrychluje vypocet

Kterou várku myslíš?

Rekl bych, ze mysli tuhle
Libor