BOINC@Poland

Contribute to bottleneck after server shutdown!!
http://boincstats.com/en/stats/challenge/team/chat/639

Miejmy nadzieję że do tego czasu serwery już będą w pełni sprawne.

Edycja:
Można już spokojnie pobierać zadnia Gamma-ray pulsar search #4 (FGRP4) na CPU i Binary Radio Pulsar Search (Perseus Arm Survey) (BRP5) na GPU. Wygląda też na to że do jutra walidator powinien zdążyć obrobić wszystko co się nagromadziło w kolejce zadań S6BucketFU1UB i pozostałe aplikacje też zostaną uruchomione.

O mały włos bym przegapił że już za niespełna 4 godziny rusza wyścig:
http://boincstats.com/en/stats/challenge/team/chat/600

Cytat: krzyszp w 30 Październik 2014, 14:18
Wyślij mi na priv wszystkie potrzebne loginy itd, w sobote uaktualnię wszystko...

Trzeba tę konserwację w końcu zrobić, bo widzę, że stada chętnych nie ma a sprawa zaczyna się sypać...

Poszło.

Cytat: AL w 30 Październik 2014, 02:06

Cytat: krzyszp w 30 Październik 2014, 01:32
...
Solucja?

1. Naprawić i zaktualizować wiki - to już powinno być zrobione, nie mam pojęcia co i dlaczego się stało...

Tu akurat innervision za nas chyba częściowo zadziałał i zaktualizował wiki odgórnie. Mchl - już wgryzł się w temat i wie co jest nie tak. Gorzej, że nie wie na razie jak to naprawić...
...

No nie do końca. Ja pisałem do Mchl-a w sprawie konieczności aktualizacji skryptów PHP już w lutym. Sytuacja była taka że praktycznie co tydzień (czasem częściej) musiałem przywracać backup-u dane i czyścić system bo ktoś się wrypał korzystając z od lat dobrze znanych dziur w sofcie. Niestety nic się w tej sprawie nie ruszyło. A ja już miałem dosyć ciągłego naprawiania zwłaszcza że ciężko było znaleźć na to czas. Więc zrobiłem upgrade niektórych rzeczy (głównie systemowych). W tym momencie w zasadzie pozostaje zrobić upgrade do aktualnej wersji wiki i smf-a i wszystko powinno działać (pisałem w tej sprawie zarówno do Mchl-a jak i GRID-a). Ja niestety nie bardzo mam czas żeby się tym dalej zająć. Mchl się do mnie odzywał w tej sprawie w sobotę i w niedzielę ale zapewne, jak widać, też nie bardzo ma czas żeby to zrobić. Może trzeba mianować nową/e osobę/y do tego typu zadań?

Już za niespełna dobę kolejny wyścig w naszym obecnym PM-ie:
http://boincstats.com/en/stats/challenge/team/chat/599

+2 godziny czyli 6:30.

Wszystkie.

Już za niespełna dobę rusza wyścig:
http://boincstats.com/en/stats/challenge/team/chat/582

Projekt już działa. W wyniku prac zmienił się adres scheduler-a. W związku z tym może być konieczne żeby kilkakrotnie ręcznie "zaktualizować projekt" zanim klient pobierze sobie nowy adres. Na razie nie działa jeszcze kilka mniej istotnych funkcjonalności w tym eksport statystyk.

Jutro (8.10.2014) od rana planowana jest przerwa administracyjna w działaniu projektu. W związku z tym wydarzeniem warto sobie zassać trochę więcej zadań.
http://einstein.phys.uwm.edu/forum_thread.php?id=10928

Odpowiedź na pierwsze trzy pytania jest bardzo prosta. Są to ustawienia wygaszacza ekranu. Jeśli go nie używasz to możesz te opcje zignorować.
Pytanie 4 dotyczy liczenia na karcie graficznej:
4.1 Ustawiasz sposób użycia karty dla zadań BRP czyli poszukiwania pulsarów w układach podwójnych w danych z radioteleskopów. Obecnie ustawienie to dotyczy dwóch aplikacji BRP4G i BRP5 i określa jaką część GPU mają one używać. Inaczej mówiąc ile zadań ma się liczyć równolegle na każdym GPU. Jeśli ustawisz 1 to znaczy że zadaniu będzie przydzielone całe GPU i będziesz liczył jedno zadanie na każdym GPU. Jeśli ustawisz 0.5 to znaczy że każdemu zadaniu będzie przydzielone pól GPU w związku z tym będziesz liczył 2 zadania jednocześnie na każdym GPU. Jak ustawisz 0.33 to 3 zadania jednocześnie itd. Ma to głównie zastosowanie dla szybkich kart które inaczej nie byłyby w pełni wykorzystane. W zasadzie jeśli masz w miarę nową i w miarę szybką kartę zalecam ustawienie 0.5.
4.2 Podobnie jak wyżej tylko dla aplikacji FGRP (obecnie FGRP4, FGRP3 już praktycznie został cały przeliczony) czyli poszukiwania pulsarów z satelity odbierającego promieniowanie Gamma.
4.3 Podobnie jak wyżej tylko dla aplikacji GW (obecnie praktycznie wszystkie próbki S6CasA zostały przeliczone) czyli próba detekcji fal grawitacyjnych w danych z grawitacyjnych interferometrów laserowych.

W tej chwili i w najbliższej przyszłości na GPU można liczyć tylko BRP4G i BRP5. Natomiast na CPU tylko FGRP4 i ewentualnie BRP4 na komórkach, tabletach itp.

Dobrze się składa bo od 11 do 16 jest w E@h wyścig:
http://boincstats.com/en/stats/challenge/team/chat/582

100M w Einstein@home :boing:

Zapraszam wszystkich do udziału w wyścigu :attack: :
http://boincstats.com/en/stats/challenge/team/chat/474

Dla informacji jeśli ktoś jeszcze nie widział:
http://www.astro.uni.torun.pl/index.php?page=rt90simulation
http://www.astro.uni.torun.pl/articles/RT90/RT90_geometry_KB.pdf

Zapraszam wszystkich miłośników tego jakże zacnego projektu do kolejnego wyścigu :attack:
http://boincstats.com/en/stats/challenge/team/chat/399

Myślę że niezłą zachętą może być fakt że w ostatnim wyścigu, który co prawda przeszedł na forum bez echa, byliśmy zwycięzcami  :parrrty:
http://boincstats.com/en/stats/challenge/team/chat/391

Einstein@home

A tak swoją drogą to czy Poem ma obecnie jakieś zadania na GPU? Jak ostatnio kilka razy próbowałem coś zassać to mi serwer odpowiadał że nie ma zadań na GPU. Może miałem pecha ale wolę zapytać.

Z tą aplikacją OpenCL do GammaRay to niestety przyjdzie nam trochę poczekać. Jest taki sam problem jak w Poem-ie. To znaczy jak jest komp z kilkoma kartami Nvidia to pada numeracja urządzeń i zdania zaczynają skakać między nimi. To prowadzi do tego że się wywalają. Co do przełączenia pozostałych BRP4 na CPU to zastanawia mnie czy nie będzie jednak możliwe użycie obecnej aplikacji GPU za pomocą app_info.xml. To co i jak ona robi zależy od parametrów konkretnego zadania (BRP4 i BRP5 używają dokładnie tej samej binarki).

Cytat: zablociak w 27 Maj 2013, 16:52
Admini Einteina są jednak głusi na prośby użytkowników i za wszelką cenę starają się równać w dół do SETI, (które z tego co wiem punktuje słabiutko) a nie do ogółu projektów z aplikacjami GPU.

To nie do końca tak jest że są zupełnie głusi. Trzeba wziąć pod uwagę że są też wolontariusze którzy na forum wygłaszali aprobatę dla niższej punktacji. Oczywiście, co raczej nie dziwi, większość jest za wyższą. Natomiast stanowisko adminów jest takie że zajmą się problemem punktacji jak tylko będą mieli na to czas. Obecnie są mocno zajęci przygotowaniami do odpalenia nowego badania dla danych z S6. W Albercie już od pewnego czasu jest testowana aplikacja która się tym zajmie - Gravitational Wave S6 Directed Search (CasA).

Validator jest obecnie celowo wyłączony. Chodzi o to że personel projektu chce uzbierać trochę próbek by na podstawie czasu jaki zajęło ich przeliczanie dobrać punktację. A drugim, ważniejszym powodem jest to że chcą bardzo dokładnie przeanalizować zachowanie całego procesu obsługi tych zadań. W związku z tym jak już uzbierają odpowiednią ich ilość zapewne na początku będą ręcznie puszczać po jednej i sprawdzać czy wszystkie etapy (validacja/assymilacja itp./itd.) działają jak powinny.


Wygląda na to że punktacja została wstępnie ustalona na 4000pkt./zadanie, i pierwsze zadania już zostały poddane walidacji :)

Ruszył nowy podprojekt Perseus Arm Survey. Jego celem jest dokładne przeszukanie pod kontem wykrywania pulsarów w jednym z większych ramion naszej galaktyki jakim jest właśnie Ramię Perseusza. Aplikacja dostępna jest jedynie na GPU ale za to poza standardowymi dziś wersjami obsługującymi Nvidia CUDA oraz ATI/AMD OpenCL dostępna jest też wersja obsługująca Intel OpenCL. Zadania zostały znacznie wydłużone w stosunku do standardowych BRP. Należy się spodziewać że jeden pakiet zajmie kilka godzin na najnowszych procesorach GPU.

Linki:
http://einstein.phys.uwm.edu/forum_thread.php?id=10028
http://mnras.oxfordjournals.org/content/early/2012/12/03/mnras.sts359.short?rss=1

Dodam jeszcze na zachętę że z racji tego że jest to całkiem gęsty obszar naszej galaktyki istnieje duże prawdopodobieństwo odkrycia nowych pulsarów :)

 :p_arr:

Wyścig już w toku. Start całkiem dobry. Obecnie zajmujemy drugą pozycję. Zachęcam wszystkich do wsparcia.  :attack:

Kontroler jest ok. i cały czas działa tyle że już w normalnym sprzęcie a nie w pececie. Niektóre kontrolery RAID mają naprawdę mocne procki i kupę ram-u + flash kilka baterii lub SuperCAP-y więc spokojnie mogą tak z 50-100W pociągnąć. Koniec końców ja myślę że to bardziej kwestia marnej jakości płyty.

Już niedługo małe after party:
http://boincstats.com/en/stats/challenge/team/chat/382

Dla uściślenia i przypomnienia wyścig startuje najbliżej nocy, tj. z 21-go na 22-go, o godzinie 2:00 naszego czasu.

Cytat: Dario666 w 18 Maj 2013, 21:17
Czy na wydajność obliczeniową w BOINC ma wpływ przepustowość portu?
Np. podłączenie 7970 do PCI-E x16 ver.1 lub włożenie jej do szlifowanego portu PCI-E x4 albo nawet x1.

Bardzo różnie z tym bywa w różnych projektach. Np. GPUGRID ładuje bardzo dużo danych do karty na starcie i potem już nie transmituje jakichś ogromnych ilości. Oczywiście czym szybsza karta tym zapotrzebowanie na pasmo rośnie. Natomiast W Einstein-ie transferów jest bardzo dużo i już np. slot 2.0 x8 będzie mieć problem z wykarmieniem karty na poziomie GTX-a 5/6/7xx czy nawet najwyższych modeli 4xx.

Jeszcze przy okazji chciałbym przypomnieć że wraz z nowszymi wersjami specyfikacji poza przyrostem prędkości wzrasta też maksymalna moc jaką można dostarczyć bezpośrednio przez gniazdo. Więc mimo że standard przewiduje że np. karta ze złączem 3.0 powinna działać w slocie 1.0 (tyle że wolniej) to trzeba mieć na uwadze że może ona mieć większy apetyt na prąd niż takie gniazdo (płyta) będzie w stanie dostarczyć. Mój znajomy właśnie tak uszkodził płytę główną bo chciał na szybko sprawdzić czy karta kontrolera RAID działa. Efekt był taki że ta karta zrobiona zgodnie ze specyfikacją 3.0 wsadzona do slotu 1.0 potrzebowała zassać z tyle prądu że popaliły się ścieżki. Jeśli dobrze pamiętam to jest jakoś tak 75W - 1.0, 150W - 2.0 i 300W - 3.0 dla pełnego slotu x16.

Ja się postaram pojawić. Ale jeśli nie uda mi się jakoś wcześniej wyjść z pracy to pewnie dotrę dopiero jakoś na sam koniec (ok. 18:00).

Kurak ja mieszkam dosłownie przecznicę obok tyle że o 15-tej to będę w pracy. Jest jakaś rozpiska czasowa co ile potrwa (o której poszczególne wystąpienia się zaczynają)? Może bym się jakoś wyrobił chociaż na kawałek?

Cytat: mariotti w 10 Maj 2013, 12:59
Technicznie mogę sobie wyobrazić że jest to możliwe, ale nie rozumiem jaki to ma sens.

Tak jak pisałem np. są zadania które wymagają tak dużej ilości pamięci że nie jest w stanie tego obsłużyć pojedyncza maszyna (tera czy petabajty). Dzięki takiemu rozwiązaniu można w miarę efektywnie wykorzystać kontrolery pamięci wielu procesorów.

Cytat: mariotti w 10 Maj 2013, 12:59
Zawsze gdy program startuje, to mamy na początku jeden wątek. Tutaj nie ma żadnych
problemów. Potem program się rozwidla albo na procesy, albo na wątki.

Gdy rozwidla się na wątki, to każdy wątek ma dostęp do swojej pamięci na stosie. Wątek jest
uruchamiany w pewnym sensie podobnie jak wywołanie procedury, a procedura ma
zarezerwowany jakiś rozmiar stosu dla siebie. Poza tym wątek ma dostęp do pamięci procesu.

Gdy rozwidla się na procesy, to zwykle przed rozwidleniem jakaś część pamięci RAM jest
oznaczana jako współdzielona przez te procesy.

Więc w obu przypadkach mamy podobną sytuację: wątki/procesy mają jakiś obszar pamięci
wyłącznie dla siebie i obszar pamięci wspólnej. W momencie gdy wątek/proces pisze albo
czyta do swojej pamięci, to nie ma najmniejszego problemu aby uruchomić go na
oddzielnej maszynie. Ale gdy dochodzi do zapisu na pamięci wspólnej, to system musi
wygenerować jakieś przerwanie, następnie musi:

Problemy synchronizacji zawsze występują w każdym środowisku w którym współbieżnie działają programy. Ba nawet przeciętna maszyna x86 z tylko jednym procesorem logicznym ma konieczność wprowadzania pewnych mechanizmów synchronizacji choćby dla ochrony obszarów transmisji DMA, urządzeń działających w trybie BusMaster czy MMIO, itp., itd.

Cytat: mariotti w 10 Maj 2013, 12:59
1) obliczenia na wszystkich węzłach zatrzymać
2) pamięć na wszystkich węzłach zaktualizować
3) obliczenia wznowić.

Jak wyżej, w środowisku współbieżnym zawsze może dojść rywalizacji o blokady. Natomiast pamięci nie musisz aktualizować na wszystkich węzłach a tylko na tym/ch który/e fizycznie ten fragment przechowuje/ą. Ewentualnie należy rozgłosić informacje o konieczności unieważnienia danej strony pamięci jeśli jest gdzieś cache-owana. Tak właśnie działa architektura ccNUMA. Która jest używana także w małych wieloprocesorowych systemach x86/x86-64 od czasów procesorów Opteron dla AMD i Xeonów bazujących na architekturze i7 u Intel-a. Tyle że tu poza załóżmy cache-m L1, L2, L3, RAM-em lokalnego kontrolera, RAM-em kontrolera w innym procesorze (+dystans do tego kontrolera, w systemach z 4 lub więcej podstawkami często nie wszystkie chip-y są ze sobą połączone bezpośredni i wtedy dostęp do pamięci może się odbywać z pośrednictwem interfejsów HT, PQI itp. innych chipów), mamy jeszcze dodatkowy poziom w postaci dostępu do pamięci znajdującej się fizycznie w innym węźle.

Cytat: mariotti w 10 Maj 2013, 12:59
Może dochodzić do takiej sytuacji, gdy dwa procesy na różnych maszynach w podobnym
czasie będą próbowały dokonać zapisu do pamięci wspólnej. Wtedy system musiałby
jeszcze rozwiązywać konflikty, musiałby jakoś kolejkować żądania zapisu.
W praktyce co jedną instrukcję może być koniecznośćtransferowania danych i w
typowych programach wielowątkowych często tak jest.

Oczywiście i dlatego tak jak dla aplikacji wielowątkowych działających w jednym systemie tak i dla takich bardziej rozbudowanych architektur istnieją odpowiednie mechanizmy które o to dbają. Istnieją rozwiązania które dbają o to by odpowiednio obsłużyć standardowe mechanizmy takie jak np. futex w takim środowisku. W zasadzie nie różnią się bardzo od tych które są używane w normalnym pojedynczym systemie z architekturą ccNUMA. System operacyjny jest tak przystosowany by starać się migrować procesy/wątki na węzły/procesory/rdzenie bliżej obszaru roboczego pamięci i/lub migrują obszar pamięci na węzeł/kontroler bliższy rdzenia na którym działa proces/wątek w zależności co uważa za tańsze i czy w ogóle ma sens. Decyzje podejmuje na podstawie pewnych standardowych algorytmów które opierają się na różnych statystykach działania procesu/wątku (typu czas działania, wielkość obszaru pamięci, ilość dostępów do pamięci lokalnej i zdalnej, proporcja ilości dostępów do pamięci w stosunku do innych operacji, odległość między aktywną jednostką wykonawczą a obszarem danych, itp., itd.), lub aplikacja może być napisana tak by informować system o swoim zachowaniu (np. w Linux-ie mamy i automatyczne mechanizmy systemowe jak i możliwość skorzystania z biblioteki libnuma itp.)

Cytat: mariotti w 10 Maj 2013, 12:59
Myślę że większość aplikacji zadziała w takim środowisku wolniej niż na jednym komputerze.

Zasadniczo masz rację. Są jednak takie zagadnienia których pojedyncza maszyn po prostu nie jest w stanie udźwignąć np. ze względu na wielkość pamięci czy jej szybkość. Czasami też utrata wydajności związana z potrzebą synchronizacji i lokalizacji w rozbudowanym systemie jest akceptowalna w stosunku do korzyści wynikających z możliwości relatywnie szybkiego (w stosunku do innych metod komunikacji) dostępu do pamięci o dużych pojemnościach. Wszytko zależy często nie tyle od samej aplikacji (w sensie jej kodu i możliwości jego modyfikacji) a od problemu jaki trzeba rozwiązać. Żeby daleko nie szukać np. w projekcie Einstein@home zanim dane są rozsyłane do ludzi są najpierw obrabiane przez klaster (bodajże nazywa się ATLAS). Wynika to z tego że danych które uzyskuje się z instrumentów typu LIGO są  ogromne ilości a trzeba je poddać najpierw wstępnej analizie przed podzieleniem żeby odnaleźć pewne ich właściwości które będą pomocne przy późniejszej analizie (którą robimy już my BOINC-iem). I potem używa się go żeby złożyć wszystkie wyniki cząstkowe (z BOINC-z) w jedną całość i poddać finalnej analizie. I właśnie dzięki takiej architekturze można załadować wszystkie te dane do pamięci klastra i mieć do nich szybki dostęp nawet w tych miejscach analizy które się słabo zrównoleglają lub wymagają całkowitej serializacji.

Cytat: mariotti w 10 Maj 2013, 12:59
Zwykle aplikacje pisane wielowątkowo nie są tego świadome, albo są świadome tylko kosztu lokalnego cache i całej pamięci.

Jeszcze do niedawna tak było. Ale z racji tego że praktycznie wszystkie nowe popularne platformy serwerowe mają architekturę ccNUMA coraz więcej aplikacji jest do niej lepiej lub gorzej przystosowana. Np. taki popularny RDBMS jakim jest MySQL w systemie Linux działającym na architekturze ccNUMA (np. już nie taki nowy serwer z dwoma procesorami Xeon E5504 z których każdy ma lokalny kontroler obsadzony modułami pamięci) instruuje system by ten starał się alokować pamięć dla wątku realizującego zapytanie jak najbliżej rdzenia na którym się ten wątek wykonuje. Natomiast w przypadku częstego dostępu do części dużego wspólnego obszaru jakim jest np. "InnoDB buffer pool" (który zwykle ze względu na swoją wielkość znajduje się fizycznie częściowo w obszarze kontrolera pierwszego procesora a częściowo drugiego) instruuje system by przeniósł wątek na rdzeń najbliższy temu obszarowi.

Cytat: mariotti w 10 Maj 2013, 12:59
Tu się zgadzam w całości. Jeśli to tylko możliwe w danym zadaniu, to należy zrobić coś podobnego do BOINC.

Dokładnie tak, niestety są zagadnienia których w ten sposób nie tyle że rozwiązać się nie da (bo zawsze się da), co byłoby to nie nieefektywne i/lub niepraktyczne.

Także pozdrawiam

Cytat: mariotti w 10 Maj 2013, 11:42

Dzięki za wszystkie odpowiedzi.  Tak właśnie mi się wydawało, że nie ma szans
aby automatycznie aplikację wielowątkową przenieść na środowisko rozproszone, a
ktoś mnie próbował przekonać że to jest możliwe :)
...

Zasadniczo możliwe jest. Widziałem takie rozwiązanie gdzie system zapewniał takie środowisko w którym cała pamięć wszystkich węzłów jest przez nie widoczna jak ich własna. Wygląda to jaka tak wielopoziomowa NUMA. Węzły były spięte Infiniband-em a wymiana pamięci odbywała się za pomocą RDMA. Migracja procesów i wątków odbywała się podobnie jak ma to miejsce w klastrach MOSIX-owych. Użycie takiego środowiska ma sens jeśli z jakiegoś powodu nie można stworzyć/dostosować aplikacji (np. nie ma dostępnych źródeł) lub zagadnienie ma np. ogromne wymagania co do pamięci. Niestety wiąże się to ze znaczną utratą wydajności. Zależy jak aplikacja używa pamięci i czy jest "świadoma" różnych kosztów dostępu do pamięci (cache, ram lokalnego cpu, ram innego cpu w tym samym węźle, ram innego węzła i tu jeszcze zależy czy jest full mesh czy do różnych węzłów koszt jest inny).

Niemniej uważam że najlepszym rozwiązaniem jest mniej więcej takie podejście jak w boinc-u. Czyli każdy węzeł liczy niezależnie swój kawałek i nie ma żadnej utraty wydajności związanej z transferami czy synchronizacją. Natomiast istnieją problemy których w takim modelu z różnych względów rozwiązać się nie da (np. potrzeba wielkich pojemności pamięci, lub wymagało by to ogromnych transferów i/czy duplikacji danych).

Używasz np. MPI/MPICH/2 lub czegoś podobnego.

Chodzi o wyrażenie poparcia dla realizacji projektu. Zapewne będzie to im pomocne przy uzyskiwaniu finansowania od różnego rodzaju agencji i instytucji czy to rządowych czy unijnych.

Na forum E@h pojawiła się prośba o wsparcie projektu eLISA. Wszystkich zachęcam do dopisania się do listy na tej stronie:
http://support.elisascience.org/

Referencja do wątku na forum E@h:
http://einstein.phys.uwm.edu/forum_thread.php?id=10103

Nasi rywale ostro się zmobilizowali i zepchnęli nas z podium. My też musimy się zmobilizować :whip:. Załoga do boju :attack:

Wyścig już się zaczął więc wszyscy chętni do boju:
http://boincstats.com/en/stats/challenge/team/chat/378
:attack:

Gdyby więcej ludzi zmobilizować to myślę że jednak dało by radę na podium wskoczyć.

Do boju :attack:

Cytat: Krzysiak_PL_GDA w 06 Grudzień 2012, 09:26
O której startuje polskiego czasu ?

13:00

Cytat: Krzysiak_PL_GDA w 05 Grudzień 2012, 00:06
...
Czy jest sens zaprzątać sobie nim głowę czy kupić SSD - któryś z nowszych
Tak się pytam bo ostatnio temat był przy piwku poruszony

Tak bawiłem się i mogę powiedzieć że do zwykłego PC-ta to zwykły SSD spokojnie wystarczy.

Cytat: Krzysiak_PL_GDA w 04 Grudzień 2012, 23:39
ad2
No właśnie bo mój HD7970 najlepiej jest wykorzystany przy 4WU tylko zajmowane są 2CPU które strasznie się nudzą  :wth:

U mnie jest podobnie, tyle że zauważyłem że jak coś wrzucę coś na te rdzenie to wydłuża to dość znacznie czas liczenia na GPU. Więc teraz na kompach z użytecznym GPU zostawiam te rdzenie wolne albo w ogóle nie liczę na nich na CPU, żeby wycisnąć maksa z GPU.