2011.08: DistributedDataMining

Zaczęty przez Arthusp, 02 Lipiec 2011, 12:26

Co policzymy w sierpniu?

ABC@home
1 (2.1%)
AlmereGrid
0 (0%)
AndrOINC
0 (0%)
AQUA@home
14 (29.2%)
CAS@home
0 (0%)
Chess960@home
0 (0%)
Climateprediction
1 (2.1%)
Collatz Conjecture
1 (2.1%)
Constallation
0 (0%)
Cosmology@home
0 (0%)
DistributedDataMining
3 (6.3%)
DNA@Home
0 (0%)
DNETC
0 (0%)
DrugDiscovery@Home
0 (0%)
EDGeS@Home
0 (0%)
Enigma@home
5 (10.4%)
eOn
0 (0%)
Evo@home
0 (0%)
FreeHAL@home
0 (0%)
Gerasim
0 (0%)
Goldbach's Conjecture Project
0 (0%)
GPUGRID
0 (0%)
Hydrogen@Home
0 (0%)
IBERCIVIS
1 (2.1%)
Leiden Classical
1 (2.1%)
LHC@Home
0 (0%)
MicroFluids@home
0 (0%)
MilkyWay@home
0 (0%)
mopac@home
0 (0%)
NFS@Home
0 (0%)
Orbit@Home
0 (0%)
POEM
1 (2.1%)
Primaboinca
0 (0%)
PrimeGrid
2 (4.2%)
QMC@home
0 (0%)
Quake Catcher Network (QCN)
0 (0%)
QuantumFIRE
0 (0%)
RNA World
0 (0%)
Rosetta@home
14 (29.2%)
RSA Lattice Siever
0 (0%)
SETI@home Beta
1 (2.1%)
SIMAP
2 (4.2%)
Spinhenge@home
0 (0%)
SZTAKI Desktop Grid
0 (0%)
The Lattice Project
0 (0%)
UCT: malariacontrol.net
0 (0%)
uFluids
0 (0%)
Vtu@home
0 (0%)
WEP-M+2 Project
0 (0%)
Yoyo@home
1 (2.1%)

Głosów w sumie: 48

Głosowanie skończone: 22 Lipiec 2011, 12:26

RAD-Poland

#80
Cytat: mimeq w 01 Sierpień 2011, 21:47
DDM  :p_arr:

Od ktorej liczmy ?
Start - PM dDM 01.08.2011 21:45
aktualizacja co 15 min

EDIT: to nie moja zasługa tylko projektu, bot pracuje co 15 to się nieźle zgrywa, zła wiadomość to w przyszłym tygodniu (od piątku do środy) staty nie będą odświeżane (wyjazd)
EDIT: przeniosłem generowanie statystyk na hosta w chmurze OVH, o ile go nie wyłączą nie będzie przerwy  :)

   
WCG:
PG:         YOYO:

     

Arthusp

Scaliłem ten wątek z wątkiem "Dogrywka".  :)

sknd

jak włączyć liczenie tego? nie mam go na liście projektów do przyłączenia się... :whistle:

Tobas

http://www.distributeddatamining.org/DistributedDataMining

to wklej

sknd


Arthusp

Cytat: apohawk w 01 Sierpień 2011, 21:13
WU na javie, porażka. (...)

Czy ktoś ma jakieś problemy? U mnie wygląda dobrze. A w porównaniu z SETI - jakoś szybko lecą punkciki. :)

Cyfron

mi też ładnie liczy wszędzie :)
Tylko jak próbki się wysypują z błędem od początku, to jest to spowodowane brakiem javy, o czym dostaje się maila z informacją :)

mimeq

W sumie niewielkim nakladem bo czesc narzeka na jave takie widoczki dzieki PM zawsze mile  :parrrty:

http://www.distributeddatamining.org/TopTeams


PanStaszek

A i w TopMembers ładnie to wygląda, bo w pierwszej dziesiątce czworo (prawie pięcioro) polskich userów.


"(...)Wrzućmy go do cysterny, nie mówi tego, co chcemy"

mimeq

Dokladnie  ;D Choc ten germaniec z pierwszego to jakas masakra 252k RACu  :fright:


PanStaszek

Pół Berlina i 4 landy na ten wynik robią  ;D


"(...)Wrzućmy go do cysterny, nie mówi tego, co chcemy"

Tomasz R. Gwiazda

w dodatku za  to co zgrabili w Polsce podczas swojego tournee :>

Telefax

Cytat: mimeq w 08 Sierpień 2011, 21:44
Dokladnie  ;D Choc ten germaniec z pierwszego to jakas masakra 252k RACu  :fright:

Ten "germaniec" to jest przecież autor projektu !!

I sądząc po wieku  raczej nie brał udziału w rajdzie po Naszym kraju  ;D

stiven

Kamraci pomóżcie :fright:

Mój Phenom 1055T na win7 x64 jakoś strasznie długo mieli próbki:

Run time (s) CPU time (s)
5627555 5312613 9 Aug 2011 9:24:40 UTC 9 Aug 2011 13:15:40 UTC Completed and validated 10,133.83 936.05 5.43 10.86 Medical Data Analysis: Laryngeal video classification v1.23
5625473 5310548 9 Aug 2011 9:24:40 UTC 9 Aug 2011 12:51:56 UTC Completed and validated 9,648.49 961.01 5.57 11.15 Medical Data Analysis: Laryngeal video classification v1.23
5623502 5308587 9 Aug 2011 9:24:34 UTC 9 Aug 2011 12:06:56 UTC Completed and validated 9,441.24 989.62 5.74 11.48 Medical Data Analysis: Laryngeal video classification v1.23


Podpowie ktoś co może być powodem? Athlon 255 na 32bit win xp liczy "normalnie" tj Run time i CPU time są zbliżone. Java aktualna. Na obu boinc 6.12.33.

Troll81

A nie masz aby jakiegoś oszczędzania energii włączonego? nie zjechał ci procesor z zegarami?

stiven


mimeq

Mam to samo na lapku z i3. Na poczatku bylo ok, teraz Run Time jest zdecydowanie dluzszy od CPU Time. Co dziwniejsze w procesach java.exe po uruchomieniu BM standardowo odpala 4x25% (2 rdzenie z HT) pozniej uzycie CPU dla kazdego procesu java.exe spada do kilku (2-10%) a mimo to ogolne uzycie % CPU jest bardzo wysokie (60-70%)  a nigdzie w procesach tego nie widac (nic nie uzywa CPU na takim poziomie). Bede w domu wrzuce jakies screeny ...


PanStaszek

Właśnie pożegnałem się z projektem. Na wiekszości maszyn inne aplikacje dzialąjące na Javie zaczęły się zachowywać chimerycznie i niestabilnie.


"(...)Wrzućmy go do cysterny, nie mówi tego, co chcemy"

sknd

mi wywala błędy w każdej próbce po ok. 15 sekundach... zdaje się że chodzi o javę, ale jre mam zainstalowane... ma ktoś na linuchu taki problem?

HaNocri

Jesteś pewien, że masz Jave od Suna, a nie np. OpenJDK? Być może rapidminer odmawia działania z inną wersją Javy.
U mnie działa ok pod Debianem 64bit i z Sun Java 6.26

dziubas

u mnie to nigdy nie chodziło pod linuksem, bez znaczenia czy java z  OpenJDK  czy sunowska: Cannot read process setup 'experiment'... chociaż plik istnieje i atrybuty dostępu chyba ma jak trzeba. Ale ja mam niestandardową instalację boinca i nie mam zamiaru tego zmieniać dla jednego projektu.
* Death is the highest priority non-maskable interrupt *

sknd

#101
wlasnie zsysam pakiet jre6, ktory jest na pewno java sun 6.26, zobaczymy czy to cos da. ten co mam zainstalowany to oracles java runtime environment, to co sciagam to sun/oracles java development kit.

EDIT:

zainstalowanie jre6 wersji 6.26 nic nie dalo, nadal wykrzaczenie po 15 s. chyba nie pomogę w projekcie miesiąca  :dunno:

stiven

Przepiąłem humorzastą maszynę na WCG. Nie znalazłem powodu focha a szkoda mocy. 

HaNocri

Z ilości problemów wychodzi na to, że java nie jest najlepszym wyborem dla tego typu projektów.

Arthusp

Apohawk wiedział co pisze o problematycznych wu na javie. U siebie zauważyłem, a właściwie dziewczyna zauważyła, że jak gra w SIMSy, to się wu wypierniczają. Nie zdarzyło się, aby się przekręciły, jak SIMSy nie były uruchomione.  :ph34r:

apohawk

Przeklęty projekt.
Probowałem dodać projekt i pobrać próbki pierwszy raz. Zwiesiło łączenie z projektami na oczekiwaniu na serwer DDM na 5 minut. Dobrze, że nie na dłużej. Chyba nie tylko WU mają na javie...
Do następnego PM.
No good deed goes unpunished.

PanStaszek

Cytat: apohawk w 19 Sierpień 2011, 15:13
Przeklęty projekt.

Normalnie na czarną listę go !  U mnie liczy już to paskudztwo tylko kilka maszyn o "małym znaczeniu strategicznym" , z pozostałych został usunięty przez egzorcystę  ;D


"(...)Wrzućmy go do cysterny, nie mówi tego, co chcemy"

Arthusp

A mi normalnie teraz każda gra wykrzacza próbki: do Simsów dołączają Mass Effect i Dragon Age! Boję się uruchomić sapera!  :wth:

Ale na szczęście jak gry nie chodzą, to się liczy.  :dunno:

Aegis Maelstrom

Niedawno dołączyłem się do drużynowej zabawy i dziś nadziałem się na opisywane przez Was problemy: co pewien czas java się wywala i nie wiem, czy to efekt jakiegoś appletu na stronie internetowej, czy projekt sam robi sobie kuku.
Na razie na punktowanie to chyba specjalnie nie wpływa (zauważyłem, że próbki z analizy danych medycznych (Medical Data Analysis) przeliczają mi się coraz dłużej, ale skutkuje to większą liczbą punktów za próbkę. Jak się ma podawany czas CPU do czasu realnego trudno na pierwszy rzut oka powiedzieć, bo przynajmniej u mnie zegar nie zmienia się co sekundę, ale skokami. Ktoś patrzył na próbki, zegarek i porównywał czas rzeczywisty z tym CPU? :)

Mam też nadzieję, że te wywalanki nie spowalniają merytorycznych obliczeń. Na razie próbki wywalone i niewywalone liczą się +/- tak samo długo, więc pozostaję optymistą w tej kwestii. :)

Aegis Maelstrom

A teraz podziwiam, jak licznik procentowy na obu próbkach idzie do przodu, by zaraz wrócić do prawie tego samego punktu, w którym był na początku cyklu. W ten sposób próbki, które były dotąd krótkie, osiągnęły ca. 50% po ponad trzech godzinach. Rewelacja, ciekawe jaki będzie wynik próbek i punktacja...

HaNocri

Jeśli liczysz na Linuksie, to końca obliczeń możesz się nie doczekać. Autor zaktualizował linuksową aplikację Medical Data Analysis w skutek czego próbki które normalnie liczyły mi się 10 do 20 minut zaczęły pokazywać czas kilku godzin i pod koniec i tak kończyły się błędem. Musiałem usunąć wszystkie zadania projektu z kolejki, po pobraniu nowych czas obliczeń wrócił do normy, aktuanie to 13 minut/próbka.

mimeq

Wprawdzie juz powoli koncowka PM, ale zastanawiam sie czy nie olac liczenia DDM ostatnio kilka razy wstrzymywalem liczenie (F.E.A.R 3) i po wznowieniu probki dochodzily do 99,9xx% i potrafila jedna z nich miec czas ponad 17h bez dalszego postepu (zanim zajarzylem i przerwalem) i zuzycie CPU na normalnym poziomie...


stasieks

Cytat: mimeq w 22 Sierpień 2011, 14:19
Wprawdzie juz powoli koncowka PM, ale zastanawiam sie czy nie olac liczenia DDM ostatnio kilka razy wstrzymywalem liczenie (F.E.A.R 3) i po wznowieniu probki dochodzily do 99,9xx% i potrafila jedna z nich miec czas ponad 17h bez dalszego postepu (zanim zajarzylem i przerwalem) i zuzycie CPU na normalnym poziomie...

I u mnie dwie próbki się w ten sposób wywaliły. Otworzyłem film w trakcie liczenia.

PanStaszek

Miałem dokładnie to samo. Zrestartowałem projekt i dalej ten sam objaw. 20h na 8 jajcach zmarnowane.


"(...)Wrzućmy go do cysterny, nie mówi tego, co chcemy"

dziubas

ditto, teraz bez pardonu wywalam wszystko co liczy się dłużej niż godzinę  :wth:
* Death is the highest priority non-maskable interrupt *

PanStaszek

Cytat: dziubas w 22 Sierpień 2011, 16:14
ditto, teraz bez pardonu wywalam wszystko co liczy się dłużej niż godzinę  :wth:

Musiałbym siedzieć i nic innego nie robić tylko sprawdzać jak się liczy na różnych maszynach  >:(


"(...)Wrzućmy go do cysterny, nie mówi tego, co chcemy"

dziubas

no tak, ja mam małą flotę i wszystko widze w boinctasku, mógłbym w nim chyba nawet ustawić odpowiednią regułę ale i tak chyba przestanę liczyć DDM. Nie pamiętam żeby kiedykolwiek wywalił mi się linuksowy boinc, a od wczoraj już 3 razy.
* Death is the highest priority non-maskable interrupt *

RAD-Poland

 :shame:
przykre, że tak jest jak opisujecie, zwłaszcza że przyczyniłem się "trochę" to wyboru dDM jako PM

liczyłem ok tygodnia dDM przed PM i do dnia dzisiejszego nie miałem żadnych problemów, poza tym, że musiałem zainstalować javę
3 linuxy (Mandriva java=1.6.0_18 i Debian java=1.6.0_22) + 3 maszyny dla testów po kilka dni pod WinXp java=1.7.0-b147
za mała i za mało zróżnicowana flota by wykryć problemy, jedynie zauważyłem, że wu liczą się szybciej pod intelami, najdłuższą próbkę liczyłem 26692,30 sek, ale to był test na hoście w chmurze, a tam moc obliczeniowa potrafi spaść do 50% ponadto w dziwnie zachowującej próbce można zobaczyć jak przebiegało jej przeliczanie dla przykładu w/w wu,

Cytat
{...}
Run:scpu=13430.9cpu=1.9tcpu=13432.8cp=13430.9done=0.50bz=69try=0
last batch finished: scpu=13430.867008 fcpu=13462.076958
{..}
Run:scpu=26623.2cpu=1.8tcpu=26624.9cp=26623.2done=0.97bz=67try=0
last batch finished: scpu=26623.167317 fcpu=26657.009432

Run:scpu=26689.0cpu=1.5tcpu=26690.5cp=26689.0done=0.98bz=67try=0
Received trickle message: finish

jak widać miała taki przebieg przy 50% połowa czasu, faktem jest że takie długie czasy występowały przy felernej wersji aplikacji v1.27 MDA

ale widać światełko w tunelu, przed nami już nie długo w PM dość stabilne projekty: Rosetta, a po nim prawdopodobnie WCG

   
WCG:
PG:         YOYO:

     

ryszard.korczyk

Potwierdzam.
Mi zablokowało na 2 kompach połowę rdzeni, próbki liczyły się 20h i nie doliczyły się, przerwałem. Kosztowało mnie to 1 miejsce w top host w projekcie. :( Teraz co parę godzin loguje się na komputery i wywalam próbki, które za długo idą.

Pozdrawiam.

PanStaszek

Ja zasadniczo problemy miałem tylko na 64bit-owych oknach. Na win 32 oraz Ubu64 nie zauważyłem problemu.


"(...)Wrzućmy go do cysterny, nie mówi tego, co chcemy"