BOINC@Poland

CytatPytanie na koniec: sprzedaż punktów wiązałaby się z oddaniem już zarobionych punktów czy zleceniem ich "nabicia" przez podanie WAK (jak na naszej giełdzie) ?

Temat trudny, ponieważ dotyczy nie nabijania kredytów przez weak key, a przenoszenia ich między userami/zespołami.

Rozwiązanie takie ma swoje zalety ale i wady. Do zalet należy to, że taka giełda byłaby znacznie bardziej "dynamiczna" niż giełda oparta na weak key. User mógłby cały czas prowadzić obliczenia na swoim koncie, a potem w sposób automatyczny sprzedać kredyty na giełdzie po aktualnym kursie.

Same stworzenie takiego rynku mogłoby spowodować to, że pojawiliby się na nim inwestorzy giełdowi, którzy na zakupie/sprzedaży kredytów próbowaliby zarobić pieniądze - tak jak jest to na prawdziwej giełdzie.

CytatTo jest chyba najważniejsze w tym wszystkim, w jaki sposób miała by sie odbywać wymiana. Wg mnie to każdy kto by chciał handlować to musiał by założyć do tego celu konto na takiej giełdzie i tylko pkt nabite na tymże kocie nadawały by sie do handlu, co za tym idzie sama giełda musiała by stworzyć takie konta z możliwością zakładania kont w projektach które by przystąpiły do giełdy. Natomiast istniejące konta w projektach mogły by służyć jedynie do odbioru zakupionych kredytów.

Do końca chyba nie rozumiem. Dlaczego istniejące konta nie mogłyby sprzedać tylko jedynie kupić kredyty?

Czytając Twoją wypowiedź syrian wpadłem jednak na nowy pomysł.

Przecież konta BOINC można byłoby podzielić na te, które mogłyby korzystać z Giełdy BOINC i te, które nie mogłyby na niej wykonywać żadnych operacji. Użytkownik podczas zakładania konta decydowałby do której grupy chce należeć. Decyzja o przynależności do określonej grupy byłaby nieodwołalna (nie można jej zmienić - ktoś mógłby zakupić X kredytów i potem zmienić rodzaj konta na ten, na którym nie wykonuje się operacji giełdowych).

Albo lepiej tak: konto bez dostępu do giełdy można zawsze zamienić na konto z dostępem do giełdy, ale konta z dostępem do giełdy nie można już zamienić na te bez dostępu do niej.

Powstanie takiego podziału rodzajów kont jest proste w implementacji. Dzięki temu nawet po rewolucjach w świecie BOINC miejsce w nim znalazłoby się także dla przeciwników nowej giełdy - mogliby oni liczyć na starych zasadach. Możliwy byłby wtedy do stworzenia ranking kont liczących BOINC ale bez dostępu do operacji giełdowych.

Czyżby to był "złoty środek"?

Drodzy liczydłowi!

Chciałbym publicznie poruszyć temat możliwości otwarcia Giełdy kredytów BOINC (BOINC Stock Exchange). Z powodu chęci zapoczątkowania publicznej debaty na ten temat postanowiłem stworzyć wątek na tym forum. Giełda kredytów BOINC działałaby na tej samej zasadzie co zwykła giełda z tą różnicą, że obracałoby się tam kredytami BOINC. Każdy więc mógłby sprzedać lub kupić kredyty wybranego projektu po ustalonym przez prawa giełdy kursie.

Temat jest dość kontrowersyjny jednak liczę owocną wymianę poglądów.

Temat koncepcji Giełdy BOINC jest bardzo szeroki i nie sposób zmieścić jego w jedynym poście. Mam jednak nadzieję, że szesnaście poniższych pytań oraz odpowiedzi na nie mogą nieco przybliżyć pomysł. Punkty te zawierają wiele koncepcji (czasem wzajemnie się wykluczających). Nie należy rozumieć ich jako jedną spójną wizję Giełdy BOINC - stanowią raczej różne przykłady problemów i możliwe próby ich rozwiązania.



1. Czy to nie zabija idei BOINC?

Na początku można pomyśleć, że tak. Jednak może okazać się, że dużo nowych osób mogłoby zacząć liczyć co byłoby plusem dla projektów i całego BOINC. To, że wyniki swojej pracy użytkownicy będą mogli sprzedać nie jest chyba niczym złym. Mało tego ci co teraz liczą np.: 8h/dobę będą chętniej liczyć całą dobę bo dzięki sprzedaży punktów będą mieli na rachunki.

Moc obliczeniowa BOINC mogłaby drastycznie podskoczyć.

Wystarczy spojrzeć na Bitcoin. Ludzie liczą jakieś "puste" hashowania. Giełda BOINC oferowałaby nam znacznie więcej. Co najważniejsze mielibyśmy do wyboru wsparcie projektu o wartości naukowej. Nie powinno być problemu z zaakceptowaniem nierówności: Bitcoin < Giełda BOINC.



2. Skąd biorą się tutaj realne pieniądze?

Otóż możemy sobie wyobrazić, że pewnego pięknego kwietniowego dnia sprzedaliśmy 10 milionów kredytów w Enigma@Home za 1 000 dolarów (taki był aktualny kurs). Tego samego dnia kupujemy za to 20 milionów kredytów SETI@Home (SETI miało bardzo słaby kurs tego dnia i myśląc, że nadejdzie hossa kupujemy kredyty tego projektu). Następnego dnia Anderson pisze, że w ciągu tygodnia mają zabrać im dostęp do teleskopu z którego pochodzą dane do projektu dlatego najprawdopodobniej w najbliższym czasie zostanie on zamknięty. Coraz więcej osób chce zebrać jak największą ilość kredytów przed zamknięciem projektu dlatego przestawiają swoje CPU/GPU na SETI@Home aby wyciągnąć ile tylko się da. Kurs kredytów w SETI@Home gwałtownie zmienia się (zmienia się ilość chętnych do kupna/sprzedaży kredytów SETI) i przyjmijmy, że wzrasta x2 w porównaniu do kursu gdy kupiliśmy w tym projekcie kredyty. Wtedy sprzedajemy je i otrzymujemy za nie 2 000 dolarów (2x więcej niż 1 000 dolarów za które kupiliśmy kredyty). Teraz kupujemy 10 milion kredytów w projekcie Enigma@Home za 1 000 dolarów (ponieważ kurs w tym projekcie nie zmienił się) i pozostaje nam 1 000 dolarów zarobione na czysto.



3. Kto mógłby na Giełdzie BOINC zarobić?

Na Giełdzie BOINC mógłby zarobić każdy. Należy jednak pamiętać, że każdy też mógłby stracić pieniądze. Z prowizji jakie pobierałaby platforma można byłoby wspierać projekty i różne inicjatywy BOINC na całym świecie.

Przykładowo można zaproponować, że pewien procent z obrotu kredytami danego projektu będzie trafiał do administratorów tego projektu na jego rozwój itp.



4. Jak wyglądałyby wpłaty/wypłaty pieniędzy do Giełdy BOINC?

Wpłaty/wypłaty można zrobić to tak jak np. w kasynach online. Użytkownik wpłaca depozyt, którego wartość jest dostępna w systemie. Potem na tych przelanych pieniądzach użytkownik może wykonywać operacje (kupować za nie akcje wybranych projektów). Jeżeli np. sprzeda określone akcje i jego depozyt się zwiększy to może wypłacić pieniądze.



5. Czy do giełdy będą mogły dołączyć wszystkie projekty?

Nie. Do giełdy mogłyby dołączyć jedynie najlepsze projekty, które posiadają odpowiedni support, istnieją odpowiednio długo i posiadają określoną inflację.

Może wydawać się, że to pewna dyskryminacja ale jest to raczej zabezpieczeniem. Do giełdy nie mógłby przystąpić każdy nowo utworzony projekt BOINC (przecież każdy może projekt założyć). Podstawą w tym przypadku jest zaufanie - w grę przecież wchodziłyby już nie tylko kredyty ale także pieniądze.



6. Czy giełda byłaby czynna 24h na dobę i czy każdego dnia mógłbym zakupić lub sprzedać kredyty?

Nie. Giełda BOINC tak jak prawdziwa giełda działałaby w ustalonych godzinach i w dni robocze. Regularne przerwy w działaniu umożliwiłyby bezproblemową m. in. konserwację i modernizację platformy.



7. Co z wyścigami BOINC? Przecież nie można z nich zrezygnować!

Ruch kredytów między użytkownikami na Giełdzie BOINC uniemożliwiałby rywalizację za pomocą wyścigów. Przecież użytkownik X mógłby w czasie trwania wyścigu kupić określoną ilość kredytów i wyprzedzić innego użytkownika Y, który kredyty liczyłby samodzielnie. Nie taka jest jednak idea wyścigów - w wyścigu największe emocje budzi ciągłe dokładanie do "pieca" i rywalizacja na aktualne moce obliczeniowe.

Wyścigi za to mogłyby funkcjonować całkowicie normalnie w okresie gdy Giełda byłaby zamknięta (soboty, niedziele, święta).


8. Co z inflacją i sprawiedliwością naliczania kredytów?

Tak jak już wcześniej zaznaczono nie ma co ukrywać ale nie wszystkie projekty będą mogły dołączyć do takiej giełdy BOINC. Projekt aby wejść na giełdę musiałby spełniać określone wymagania co do inflacji.

Łatwo można policzyć inflację roczną projektów dysponując danymi z BOINCStats (total creditem i ilością kredytów wyrobionych w danym dniu). Można zauważyć, że World Community Grid będzie miał inflację roczną na poziomie 20%, SETI@Home około 25%, Radioactive@Home za to aż ok. 90% (ze względu na to, że to stosunkowo nowy projekt, a liczba czujek wzrasta). Do puli projektów mało inflacyjnych nie kwalifikują się DistrRTgen ani GPUGRID.

Zresztą faktem jest to, że duża inflacja nie będzie sprzyjała projektowi, a co za tym idzie jego akcje będą mniej poszukiwane na giełdzie (nawet jeżeli się na niej znajdzie). Nikt nie będzie chciał kupić takich kredytów DistrRTgen, a lepsze będą jak widać po inflacji World Community Grid. W idei pomysłu było to, że procent od operacji na akcjach danego projektu będą dostawać jego admini. Admini więc będą bardziej przykładać się do tego aby ta inflacja była stosunkowo niska, ponieważ tak jak piszę inaczej nie będzie się im to opłacało.

Zresztą co tutaj dużo pisać - może to się tylko przyczynić do lepszego pilnowania jakości naliczania kredytów. W tym systemie możemy otrzymać raczej mniej kredytów, a nie więcej niż powinniśmy.



9. Co z podziałem punktów uzyskanych na CPU / GPU?

Będzie musiał zostać zachowany podział pomiędzy projektami (podprojektami) CPU, a GPU.



10. Przyjmijmy, że jako członek teamu sprzedam swoje kredyty. Czy dorobek mojego zespołu zmniejszy się o sprzedane kredyty? Czy handel kredytami pomiędzy zespołami powinien być możliwy?

Sprawa nie jest taka prosta. Jeżeli zechcemy aby w aktualnym systemie, który działa w większości projektów BOINC (punkty obliczone w zespole zostają w nim nawet po zmianie przez użytkownika teamu) dochodzi do dodatkowych komplikacji.

Przyjmijmy, że mamy użytkownika X. Liczy on jednego dnia 12 godzin dla zespołu T1 (800 kredytów), 6 godzin dla zespołu T2 (400 kredytów) i 4 godziny dla zespołu T3 (300 kredytów). Potem chce sprzedać 1000 kredytów dla użytkownika innego teamu. Jeżeli zdecydujemy się na to, że kredyty przechodzą nie tylko z użytkownika do użytkownika ale także z teamu do teamu to od którego teamu należy odjąć kredyty?

Jeżeli zechcemy odejmować to chyba od ostatnich zespołów w jakich był user czyli tak: 300 kredytów z T3, 400 kredytów z T2 i 300 kredytów z T1. Nie możemy przecież odjąć wszystkich 1000 kredytów od zespołu T3, ponieważ user nie ma w nim nawet takiego wkładu.

Serwer BOINC nie wie na ten temat nic. Statystyki swoją drogą ale do podejmowania decyzji na ten temat potrzeba w najgorszym przypadku statystyk z całego czasu istnienia projektu. Sporo to chyba komplikuje.

Można faktycznie pozostawić teamy w świętym spokoju i niech zostaje wszystko tak jak jest (operacje giełdowe nie będą ich dotyczyły). Można też zrobić tak, że total credit teamu byłby zawsze równy kredytom sumie ich członków (kredyty przechodzą za użytkownikiem z teamu do teamu - o czym pisałem wcześniej) i wtedy operacjami giełdowymi objąć także zespoły.

Wydawaje się, że objęcie operacjami giełdowymi także zespołów może wyjść na plus giełdzie. Uruchamia to dodatkową płaszczyznę do rywalizacji między zespołami.



11. Handel między zespołami to beznadziejny pomysł. Inny zespół zapłaci i śmignie kilka razy w statystykach mój team. Jest na to jakaś rada?

Trudno przewidywać i przy wprowadzeniu Giełdy BOINC wszystko mogłoby się wydarzyć. Każdy kij ma jednak dwa końce - jeżeli jeden zespół kupi (otrzyma) kredyty to jakiś inny musi je sprzedać (stracić). Ilość kredytów na rynku pozostaje ta sama (nie licząc tych które ubijamy licząc) i nie ma tutaj jakiegoś cudownego rozmnożenia. Więc dzięki temu, że team X kupi określoną ilość kredytów od teamu Y zespół Z może nie tylko spaść w rankingu względem X ale także awansować względem Y (ponieważ ten kredyty straci).



12. Jak rozwiązać kwestię kredytów uzyskiwanych w podprojektach? Czy w jakiś sposób można byłoby zakupić/sprzedać kredyty nie tyle projektu co konkretnego jego podprojektu?

Na BOINC podprojekty mogłyby być tak samo traktowane jak projekty. Jeżeli dany projekt posiadałby podprojekty to do obrotu giełdowego wchodziłyby kredyty konkretnych podprojektów (użytkownik mógłby zakupić kredyty, które jego interesują). Jeżeli natomiast projekt nie posiadałby żadnych podprojektów to na rynek wchodziłyby kredyty z pola "total credit".



13. BOINC straci sens. Przecież jeżeli będzie można kupić kredyty to nikt nie będzie ich liczył tylko wszyscy będą kupować.

Ale przecież aby kupić to ktoś z drugiej strony musiałby je sprzedać, a aby sprzedać musiałby je zdobyć obliczając (lub np. kupując wcześniej za niższą cenę). Przecież nie ma czegoś takiego, że wszyscy przestaliby liczyć bo mogliby sobie kupić kredyty.



14. Czy możliwe byłoby znalezienie "złotego środka" pomiędzy userami chcącymi wykonywać operacje giełdowe, a tymi nie wykonujących ich nigdy?

Konta BOINC można byłoby podzielić na te, które mogłyby korzystać z Giełdy BOINC i te, które nie mogłyby na niej wykonywać żadnych operacji. Użytkownik podczas zakładania konta decydowałby do której grupy chce należeć. Decyzja o przynależności do określonej grupy byłaby nieodwołalna (nie można jej zmienić - ktoś mógłby zakupić X kredytów i potem zmienić rodzaj konta na ten, na którym nie wykonuje się operacji giełdowych).

Albo lepiej tak: konto bez dostępu do giełdy można zawsze zamienić na konto z dostępem do giełdy, ale konta z dostępem do giełdy nie można już zamienić na te bez dostępu do niej.

Powstanie takiego podziału rodzajów kont jest proste w implementacji. Dzięki temu nawet po rewolucjach w świecie BOINC miejsce w nim znalazłoby się także dla przeciwników nowej giełdy - mogliby oni liczyć na starych zasadach. Możliwy byłby wtedy do stworzenia ranking kont liczących BOINC ale bez dostępu do operacji giełdowych.



15. Co jeżeli na rynek wejdzie kilka użytkowników posiadających miliardy kredytów i chcących je sprzedać po bardzo niskiej cenie - niższej niż koszty energii elektrycznej potrzebnej do ich wygenerowania? Przecież może to zdestabilizować Giełdę BOINC, a nowym użytkownikom nie będzie się opłacało na nią wchodzić.

Jest to poważny problem Giełdy BOINC. Można spróbować ten problem rozwiązać na kilka różnych sposobów.

Można ustalić kurs minimalny kredyta np. na 75% kosztu jego wytworzenia. Koszt wytworzenia byłby obliczany na podstawie najlepszego dostępnego zestawu do obliczeń oraz jakiejś tam stawki za energię elektryczną i byłby różny dla różnych projektów na Giełdzie BOINC.

Można także wprowadzić limit wrzucania na giełdę kredytów które sie wypracowało w ciągu doby. Nie chodzi tutaj o jakiś stały limit a ograniczenie na podstawie np. średniej dziennej ilości kredytów w ostatnim tygodniu.

Przykład: W ciagu 7 dni zdobył 7000 kredytów podzielić to na 7 (ilość dni w tygodniu) wyszło by 1000 na dobę + 20% (stopniowe uwalnia tego co juz jest) co by dało 1200 i tyle mogły wrzucić na dobę kredytów na giełdę. Można przemyśleć wprowadzenie mechanizmu zliczającego nieobecność na giełdzie i automatycznie umożliwiającego dołożenie do giełdy następującej ilości kredytów: ilość kredytów średniej dziennej x ilość dni nie obecności na giełdzie.

Plus takiego mechanizmu że uniemożliwiło by dopływ dużej ilości kredytów które zalega obecnie u ludzi, zablokowało by tych co juz przestali bawić sie a chcieli by tylko pozbyć sie istniejących kredytów (zmusiło by ich do ponownego liczenia aby móc wystawić to co mają).



16. Czy będą chętni do korzystania z Giełdy BOINC?

To bardzo trudne pytanie. Trudno powiedzieć. Wszystko zależy od nas samych i tego czy pomysł ma szanse przyjąć się. Giełda nie jest dedykowana tylko dla użytkowników jednego forum lub osób pochodzących z określonego kraju, a miałby być to twór międzynarodowy. Gdy zbierzemy wszystkich potencjalnych użytkowników giełdy z całego świata i osoby, które po otwarciu takiego instrumentu świeżo dołączą - ich ilość może być wystarczająca.

Cytat: KropelkaRosy w 26 Lipiec 2013, 18:30
Taki przstojny facet i taki nie mily a fe !  :o

Zamiast grzecznie podziekowac za mile zaproszenie i powitac to on z banem wyskakuje (donosiciel?)

Dawno tak dobrego tekstu nie przeczytałem  :deadman: %)

Taski najlepiej aby były tworzone w mierę potrzeb. Nie wszystkie jednocześnie do bazy ale po części (ale to z czasem można dorobić).

Czas jednego zadania to jakoś kilka godzin. Ustaw na 5 godzin i będzie git.

Cytat: mariotti w 24 Lipiec 2013, 07:10
Jakie zadanie proponujecie na następny test? Program upper-case był dobry
do sprawdzenia czy serwer w ogóle działa. Teraz by się przydało coś ciut trudniejszego
do policzenia. Tak żeby można było po zakończeniu obliczeń podsumować wyniki i
sprawdzić czy wszystko się zgadza. Jednocześnie zadanie nie może być zbyt
trudne w implementacji.

Pozdrawiam

Jak to jaki? Teraz chyba już Twój algorytm.

Lepiej sobie darować Pi (przecież i tak wszyscy będą liczyć do tej samej precyzji) itp. co tylko będą marnować moc obliczeniową.

Wykorzystałem bibliotekę mpmath dla Pythona:

http://mpmath.googlecode.com/svn/trunk/doc/build/functions/zeta.html

Można ją łatwo zainstalować na Linuxie (jeżeli jest dostępna w repo):

apt-get install python-mpmath

Potem już według wcześniej podanej strony wystarczy tylko np.:

>>> from mpmath import *
>>> mp.dps = 25; mp.pretty = True
>>> zeta(-3+4j)
(-0.03373057338827757067584698 + 0.2774499251557093745297677j)

Wartości dla części rzeczywistej <1 muszą dać się policzyć. Funkcja dzeta ma miejsca zerowe. Pierwszym z nich jest 0.5+14.134725141734693790457251i i dla niego mpmath zwraca (-1.048365080558823465032955e-16 + 6.585259277605158331268578e-16j) - czyli prawdłowo.

Cytat: stiven w 19 Lipiec 2013, 21:45
I zasadniczo z tego co ja wiem to aby ten szereg był zbieżny to część rzeczywista musi być większa od... 1.

Zgadza się. Właśnie sprawdziłem programem i dla części rzeczywistej większej od 1 wynik wychodzi z wielką precyzją dokładny. Potem jeszcze dokładniej to sprawdzę.

Tylko co jeżeli ja nie mogę tak się ograniczać?

Mamy taką oto funkcję:



Dla argumentu 0.5+14i dość dokładna aczkolwiek także przybliżona wartość tej funkcji to:

0.0222411426099935892462132 - 0.1032581232664500579023631i

Spróbujmy sami to policzyć dla kilku pierwszych wyrazów według wzoru.

Dla czterech wyrazów (razem z jedynką) mamy więc:

1 + 1/(2^(0.5+14i)) + 1/(3^(0.5+14i)) + 1/(4^(0.5+14i)) =
= (1+0i) + (1+0i)/((2+0i)^(0.5+14i)) + (1+0i)/((3+0i)^(0.5+14i)) + (1+0i)/((4+0i)^(0.5+14i)) =
= (1+0i) + (1+0i)/(-1.3594-0.3898i) + (1+0i)/(-1.6400+0.5569i) + (1+0i)/(1.6960+1.0599i) =
= (1+0i) - 0.6797+0.1949i - 0.5467-0.1856i + 0.4240-0.2649i =
= 0.3203-0.1949i - 0.5467-0.1856i + 0.4240-0.2649i =
= -0.2264-0.0093i + 0.4240-0.2649i =
= 0.1976-0.2742i

Dla pięciu wyrazów (suma czterech wcześniejszych plus piąty):

0.1976-0.2742i + 1/(5^(0.5+14i)) =
= 0.1976-0.2742i + (1+0i)/(-1.9167-1.1515i) =
= 0.1976-0.2742i - 0.3833+0.2303i =
= - 0.1857-0.5045i

Dla sześciu wyrazów:

- 0.1857-0.5045i + 1/(6^(0.5+14i)) =
= - 0.1857-0.5045i + (1+0i)/(6^(0.5+14i)) =
= - 0.1857-0.5045i + (1+0i)/(2.4466-0.1177i) =
= - 0.1857-0.5045i + 0.4077+0.0196i =
= 0.222-0.4849i

Dla siedmiu wyrazów:

0.222-0.4849i + 1/(7^(0.5+14i)) =
= 0.222-0.4849i + (1+0i)/(7^(0.5+14i)) =
= 0.222-0.4849i + (1+0i)/(-1.3584+2.2703i) =
= 0.222-0.4849i - 0.1940-0.3243i =
= 0.028-0.1606i

Dla ośmiu wyrazów:

0.028-0.1606i + 1/(8^(0.5+14i)) =
= 0.028-0.1606i + (1+0i)/(8^(0.5+14i)) =
= 0.028-0.1606i + (1+0i)/(-1.8923-2.1021i)
= 0.028-0.1606i - 0.2365+0.2627i =
= -0.2085-0.4233i

Dla dziewięciu wyrazów:

- 0.2085-0.4233i + 1/(9^(0.5+14i)) =
= - 0.2085-0.4233i + (1+0i)/(9^(0.5+14i)) =
= - 0.2085-0.4233i + (1+0i)/(2.3795-1.8269i) =
= - 0.2085-0.4233i + 0.2644+0.2029i =
= 0.0559-0.2204i

Dla dziesięciu wyrazów:

0.0559-0.2204i + 1/(10^(0.5+14i)) =
= 0.0559-0.2204i + (1+0i)/(10^(0.5+14i)) =
= 0.0559-0.2204i + (1+0i)/(2.1567+2.3126i) =
= 0.0559-0.2204i + 0.2156-0.2312i =
= 0.2715-0.4516i

Dla jedenastu wyrazów:

0.2715-0.4516i + 1/(11^(0.5+14i)) =
= 0.2715-0.4516i + (1+0i)/(11^(0.5+14i)) =
= 0.2715-0.4516i + (1+0i)/(-1.8281+2.7672i) =
= 0.2715-0.4516i - 0.1662-0.2515i =
= 0.1053-0.2001i

Suma dla pierwszych dwudzistu wyrazów wynosi: -0.2044+0.3320i, a dla dwustu już -0.9251+0.2422i. Jak widać wzrost ilości iteracji objawia się zwiększeniem błędu zamiast jego zmniejszeniem. Pytanie dlaczego tak jest? Gdzie mam błąd? Muszę jeszcze dodać, że akurat w tym przypadku błąd się zwiększa. Czasem wyniki są od razu złe, a czasem dobre (przy uwzględnieniu, że są one przybliżone). Jest to jednak chyba kwestią przypadku.

Plik z kodem źródłowym można podejrzeć tutaj: http://code.google.com/p/olib/source/browse/trunk/samples/mathematics/riemann_zeta.cpp. Jak łatwo zauważyć operacje na liczbach zespolonych sam implementowałem ale dobrze je przetestowałem i wygląda na to, że działają ok.

Co w tym wszystkim nie gra?

Ostatecznie wygrał styczeń.

Mariotti o wszystkim pisze na forum - to w sumie nawet lepiej bo pozostaje na przyszłość dla potomnych.

Ja mógłbym coś spróbować zrobić ale raczej potrzebowałbym zdalnie zalogować się na hosta z projektem i tam pogrzebać.

Sam też kiedyś o napisaniu jakiegoś tego typu systemu myślałem ale odpuściłem sobie.

Oprócz BOINC istnieje wiele innych platform do obliczeń rozproszonych. Nie wiem czy są darmowe ale są.

Pierwszy przykład to Globus:

CytatThe Globus® Toolkit is an open source software toolkit used for building grids.

http://www.globus.org/toolkit/

Podbijam temat.

Może to:

http://www.dobreprogramy.pl/Kurupira-WebFilter,Program,Windows,27721.html

lub coś innego:

http://www.dobreprogramy.pl/Kontrola-rodzicielska,Kategoria,Windows,84.html

Cytat: Szopler w 13 Lipiec 2013, 21:06
Nic dziwnego skoro masz: upload/download server   x   Disabled

To nic do tego nie ma. W OProject@Home też mam wyłączony upload/download server i zadania są normalnie przydzielne. Na to nie ma co zwracać uwagi bo to odnosi się do czegoś innego.

Nie rozumiem za bardzo ostatniego pytania.

Dodałeś aplikację na Linux'a 64-bit i musisz połączyć się za pomocą klienta z takiej maszyny. Z innych systemów operacyjnych nie pobierzesz zadań.

Te numerki na końcu oznaczają wersję klienta BOINC.

Ok. Właśnie te www trochę mnie zmyliło.

Pod jakim adresem www masz cgi?

Dlaczego masz tak dziwną ścieżkę? Sam coś kombinowałeś czy standardowo była taka?

Najprawdopodobniej coś namieszałeś podczas zmiany URL projektu i teraz nie chce łyknąć.

To teraz tak: Weź spróbuj taki wariant jak na początku. W katalogu lokalnym archiwum ze skompresowanymi plikami i ten slide_show:

http://atom.oproject.info/slide_show2

Zobaczmy czy teraz odpali dobrze.

To teraz tak.

Skasuj ten folder slide_show_images z zawartością. Skasuj także archiwum znajdujące się lokalnie. Zostaw jedynie lokalnie rozpakowane pliki z grafiką i program slide_show. Zobacz czy się odpali i upewnij się, że w katalogu nie ma żadnych plików ukrytych.

Spróbuj w tym katalogu gdzie jest slide_show utworzyć podkatalog slide_show_images i wrzuć tam slide_show_images.zip.

Zobaczymy po tej zmianie wynik.

Posiada może ktoś jakiegoś Linux'a 64-bit z serwerem X'ów? Potrzebuję upewnić się czy wygaszacz ekranu działa.

Można pobrać archiwum z:

http://atom.goldbach.pl/slide.zip

Należy następnie archiwum rozpakować i uruchomić zawarty w nim plik slide_show. Nie należy rozpakowywać pliku slide_show_images.zip - powinien pozostać w katalogu normalnie bez rozpakowywania.

Gdyby ktoś miał możliwość przetestowania to bardzo bym prosił.

Tak jak w temacie. Wybierajcie miesiąc dla Polish BOINC Conference.

Coś cisza.  :attack:

Cytat: mariotti w 09 Lipiec 2013, 18:25
Nie wiem w czym się doszkolić i z jakich materiałów. Z ostatnich
materiałów jakie mi polecono, wynikało żeby pobrać źródła, a teraz
że mam instalować binarkę - tak nikt nie jest w stanie się nauczyć.

Najlepiej pobrać z źródła.

Cytat: mariotti w 09 Lipiec 2013, 18:25
W ogóle jakie jest uzasadnienie że Debian jest lepszy do BOINC
niż inne dystrybucje? Ale pytam o konkretne uzasadnienie.

Nie ma takiego. Większość osób stawia na Debianie ale na Ubuntu też widziałem jakiś stary poradnik.

Cytat: mariotti w 09 Lipiec 2013, 18:25
Może ten Debian jest uszkodzony i dlatego nie mogę nawet PHP
zainstalować?

Możliwe ale raczej mało prawdopodobne.

Ja jednak polecam Debiana. Ubuntu może trochę namieszać.

Cytat: mordi w 08 Lipiec 2013, 17:28
właśnie problem największy jest z terminami... niestety czasem bywają koszmarne obsuwy :/

Może bezpieczniej aby wydaniem zajęła się już Fundacja? Znając życie uczelniane to może okazać się, że na taki wydruk potrzebny będzie przetarg, który ciągnąć się będzie miesiącami. Fundacja wystąpiłaby o ISBN i też byłoby git. Z drugiej strony wydawnictwo AON bardziej renomowane.

Jaki termin (miesiąc) byłby bezpieczny? Grudzień to nie za wcześnie?

Dobry pomysł z tym wystąpieniem o patronat do ministerstw.

Trochę się zdziwiłem. Aż tyle uda Ci się załatwić? Nawet mogą wydać publikację pokonferencyjną? To nieźle. Myślałem, że książkę wyda Fundacja, ale jeżeli Wasze wydawnictwo to chyba jeszcze lepiej. Tylko czy oby na Uczelni wydanie takiej małej książeczki nie będzie związane z opóźnieniami? Książka powinna być dostępna już na konferencję. W miesiąc wyrobią się z drukiem?

Nie wiem tylko jak ze sponsorami ale najpierw musimy mieć znaną datę. Jaki miesiąc?

Najpierw trzeba wiedzieć czy konferencja będzie trwać jeden czy też dwa dni. (?)

Jeden dzień na początek wydaje się ok ale trudno w takim przypadku zapraszać gości z zagranicy.

Musimy wiedzieć ilu będziemy mieli wykładów "pewniaków":

1. Fundacja BOINC Polska
2. Radioactive@Home
3. Enigma@Home
4. OProject@Home

Napisałem do Sebastiana M. Bobreckiego to być może:

5. Mersenne@Home

Kolejny problem poruszył Troll. Za co byśmy musieli zapłacić? Wydaje mi się, że noclegi opłacić będą musieli sobie sami uczestnicy. Na posiłki także nas za bardzo nie stać więc to we własnym zakresie.

Na nasze barki zrzuciłbym tylko wydruk jakichś materiałów promocyjnych (plakatów itp.) oraz książki pokonferencyjnej z referatami w jakimś niewielkim nakładzie. Trzeba byłoby spytać Fundację czy w takim wymiarze moglibyśmy otrzymać finansową pomóc. Może jakieś drobny poczęstunek między wykładami dodać? Nie wiem. Potrzebna wypowiedź większej ilości osób.

Temat umarł.

Trochę jednak od czasu ostatniego podejścia do konferencji się zmieniło. Rozmawiałem ostatnio z mordim i nie byłoby problemu z salą na czas konferencji w Warszawie (AON). Lokalizacja więc dość dobra.

Może by tak spróbować coś drgnąć?

Mam dziwny problem z programem. Otóż jeżeli kompiluję jego z optymalizacjami dla CPU i O3 to wykonuje się teoretycznie poprawnie. W przypadku gdy kompiluję bez optymalizacji CPU i z O2 podczas uruchamiania dostaję "Segmentation fault".

Program można pobrać z repozytorium googlecode:

svn checkout http://olib.googlecode.com/svn/trunk/ olib

Następnie należy wejść do odpowiedniego katalogu z przykładami:

cd olib/samples

I wykonać odpowiednie polecenie make:

make goldbach_odd

Po kompilacji program będzie znajdował się w podkatalogu mathematics, który znajduje się w katalogu samples.

cd mathematics

Wystarczy uruchomić program odpowiednią dość długą komendą:

time env OMP_NUM_THREADS=2 ./goldbach_odd 100000000209366024193 10000000000000000000000

i program powinien zwrócić Segmentation fault.

Można spróbować dodać optymalizacje CPU w pliku makefile (olib/samples/makefile). Odpowiada za to 71 linijka:

CPU_OPTYMALIZATION = no

Próbowałem debugować programem gdb. Udało mi się jednak uzyskać tylko:

Program received signal SIGSEGV, Segmentation fault.
0x000000000041de43 in __gmpz_set_str ()

Nic mi to nie mówi. Błąd z pewnością jest w sekcji OPenMP w pliku olib/samples/mathematics/goldbach_odd.cpp

    #pragma omp parallel shared(S, add_1, add_2, number_of_threads) private(thread_id, number, upper_range, counter)
   {


   }

Błąd jest jednak niezależny od ilości wątków na których będzie wykonywany program - występuje nawet gdy program uruchomimy na jednym wątku.

Czy ktoś mógłby pomóc i zrobić porządne debugowanie tego programu?

Możliwe, że GMP jest słabo zoptymalizowane pod Windows. Najprościej nie korzystać z WIndowsa, a przenieść się na Linuxa. Linux bardziej nadaje się do takich obliczeniowych zastosowań.


W załączeniu podaję skompresowany program do testów.

Należy jego uruchomić na Linux'ie 64-bit następująco:

time env OMP_NUM_THREADS=X ./goldbach_odd 100000000209366024193 1000000000000000000000

time env OMP_NUM_THREADS=X ./goldbach_odd 100000000209366024193 10000000000000000000000

time env OMP_NUM_THREADS=X ./goldbach_odd 100000000209366024193 100000000000000000000000

time env OMP_NUM_THREADS=X ./goldbach_odd 100000000209366024193 1000000000000000000000000


gdzie X oznacza ilość wątków.

Proszę o informację jakie czasy udało się Wam uzyskać.

Cytat: Dario666 w 30 Czerwiec 2013, 11:09
Jak GSCE-SV może być tak źle zoptymalizowany, że na Linuxie liczony jest 2 godziny, a na Windows minimum 6 godzin.

To kwestia biblioteki GMP, która na systemach Windows 64-bit ogranicza się do typów 32-bit. Na Linuxie 64-bit wykorzystywana jest cała arytmetyka.

Dokładnie tak jak pisze Dario666 - nie ma metody, a gdyby była to już dawno ktoś by to rozgryzł.

Sprawa jest dość ciekawa. Aż się zdziwiłem, że wcześniej o tym nie słyszałem.

Pierwszym problemem jest to, że książka jest udostępniona w wersji graficznej, a trzeba byłoby ją jakoś przekonwertować do kodu, który potem da się analizować algorytmem. Jest to dość trudne ponieważ jak czytałem istnieje nawet dyskusja nad tym ile tam istnieje liter w alfabecie. Jeżeli nawet tego nie jesteśmy pewni to trochę lipa...

My też bijemy rekord Guiness'a?

Aktualnie testuję pewną aplikację i w najbliższym czasie będę potrzebował pomocy.

Pomoc ta dotyczy odpalenia pewnego progrosa z palca na sporej ilości komputerów. Jeżeli wyniki będą ok to mógłbym dodać progrosa do BOINC.

Czy ktoś byłby chętny pomóc? Wspierane platformy to Linux 32/64bit. Oczywiście za wykorzystany czas dopiszę ręcznie kredyty w projekcie OProject@Home.

Dyski SSD raczej nie nadają się do serwerów baz danych. W profesjonalnych sprzętach stosuje się SAS i SCSI.

Dysk SSD przy takiej bazie o której tutaj mówimy najprawdopodobniej za długo by nie przetrwał (przecież tutaj mamy maksymalny io wait). Takich twardzieli właśnie z takich względów nie ustawia się na swap - przy normalnej eksploatacji komputera po pół roku sprzęt idzie na szrot. Pół roku przy normalnej eksploatacji to nie wiem ile by wyszło dla maksymalnego io wait - miesiąc?

Może i SSD są i coraz lepsze ale tutaj potrzeba jakiejś profesjonalnej macierzy. Ktoś oszacował ile ta baza będzie zajmowała? Jeżeli jest to rząd wielkości mierzony w TB to nie wiem czy warto kombinować, bo może okazać się, że zapytania będą szły zbyt wolno aby zgrać to w jakiś realny skrypt. Zależy co tam będzie robione.

Jestem sceptycznie nastawiony ale myślę, że mogę pomóc ale musisz mariotti oszacować jakiego sprzętu potrzebujesz (jaka pojemność, jaka prędkość odczytu/zapisu) i na jak długo.

Serwer BOINC można spokojnie stawiać na MySQL.

Co do includowania bibliotek MySQL to przecież w aplikacji liczącej nic takiego nie powinno być dodawane. Mamy więc problem z głowy.

Ogólnie dyskusja zeszła na trochę inny temat.

Panowie nie chcę nikogo trochę hamować ale niestety większości ze spraw o których tutaj jest pisane odnośnie obliczeń rozproszonych nie ma najmniejszych szans realizacji.

Droga od postawienia serwera BOINC do czegoś takiego o czym piszecie jest bardzo długa i zawiła. Jak czytałem mówimy tutaj o serwerze master, który dosyła dane do klientów i o jakimś skalowaniu wątków, wewnętrznych benchmarkach oraz aplikacjach działających na różnej ilości wątków. Niestety 99% z tego trzeba wsadzić do kosza. Nawet najlepsze projekty różnie działają, a różnica między pierwszym projektem, który sobie na szybkiego odpalimy a czołówką najlepszych jest gigantyczna.

Do czegoś takiego najprawdopodobniej łatwiej byłoby napisać własny soft w postaci klienta i serwera i udostępnić liczącym. Wtedy mamy całkowitą dowolność i pisząc całość od zera w technologii, którą znamy możemy coś takiego zrobić.

Tak napisać, że serwer ma robić X, a klient to będzie sobie pobierać Y i skalować odpowiednio tylko wątki to prosto. Problem jednak zamknie się na tym, że podczas konfiguracji wyskoczy jeden błąd i będzie kaplica. Alarmuję więc - nie twórzmy wielkich teorii o tym jak ma działać serwer BOINC, a dostosujmy się do tego jak jest on skonstruowany.

Koncepcja podstawowej aplikacji BOINC jest szalenie prosta.

1. Serwer tworzy zadanie
2. Klient pobiera aplikację liczącą i zadanie
3. Klient wykonuje obliczenia sekwencyjnie na jednym wątku i zapisuje wyniki do pliku
4. Klient odsyła dane (także plik wyniku) do serwera
5. Serwer analizuje nadesłane dane

Nie ma tutaj miejsca na jakąkolwiek komunikację w środku wykonywania zadania. Jedyna znacząca komunikacja to pobieranie zadania i odsyłanie wyników. Zadania także nie mogą być liczone w dziesiątkach czy też setkach na jednym kliencie w jakimś krótkim odcinku czasowym. Żaden serwer BOINC tego nie obsłuży. Każde zadanie powinno wykonywać się przynajmniej godzinę.

Znak zapytania bym postawił przy samych aplikacjach wielowątkowych, pomimo, że takie BOINC wspiera.

Przepraszam za takie oblanie zimną wodą ale niestety tak to wygląda. Oczywiście można zrobić wszystko - pytanie tylko czy ktoś zdoła obejść wszystkie problemy. Wydaje mi się, że nie jest to tego kalibru problem aby pisać pod niego na nowo pół środowiska serwera BOINC.

Ja mogę udostępnić kawałek OProject@Home. Aplikacja jednak musi być raczej jednowątkowa. Nie wiem też jak z dostosowywaniem jej do BOINC - większością spraw mogę się zająć ale częścią już nie.

Nowy admin by się przydał  :parrrty:

Cytat: sknd w 30 Maj 2013, 13:45
mam nadzieję, że to, ze ustawiłem boinca na 25% procesorów, by pozostałe rdzenie się nie nudziły, nie będzie wpływać na wyniki?

Może mieć wpływ ale jak duży to już nie wiem. Zależne od procesora i tego co się na nim liczy.