BOINC@Poland

Niestety kompliator intela nie sprawdza się w przypadku procków AMD.
Również przetestowałem nową aplikację i jest u mnie wolniejsza o ok 60s na WU.
procesor to AMD X2

Jedyne wyjście to stosowanie starej aplikacji z odpowiednim app_info.xml.

Kompów z prockami intela jest dużo więcej, plus z reguły są dużo mocniejsze więc taka zmiana miała sens.

tu coś znajdziesz
http://aqua.dwavesys.com/faq.html

wysłana 5 ale czerwca

Mocne 2 rdzednie z porządnym benchmarkiem liczyły WU (160 qubit) aplikacją linuksową
prawie 29 dni
http://aqua.dwavesys.com/show_host_detail.php?hostid=9356

Pod win 64 taką WU liczy się na dobrym kompie z 8-12h.
Chyba, że te raportowane czasy źle odczytuję.

Coś mnie podkusiło aby zabrać się za liczenie tego projektu na CPU pod linuksem.
Bez przeprowadzenia wcześniejszego rozeznania.

Po 64h przerwałem mielenie dwóch WU (240 qubit), na liczniku miały 5,5791%. :o
W takim tempie końcowy czas liczenia wyniósłby ok 55-60 dni. Makabra.

Rozumiem, że priorytetem dla developerów tego projektu jest aplikacja pod GPU.

Tylko się pytam jaki jest sens wysyłania do hostów linuksowych aplikacji pod CPU,
jeżeli jej wydajność jest katastrofalnie słaba. Przejrzałem sporo wyników różnych kompów
i wygląda na to, że aplikacja pod

win 32-bit jest ok 10x szybsza, a pod
win 64-bit 60-80x

Różnice są astronomiczne, jeden komp liczy w 12h a drugi o porównywalnej mocy,
taką samą próbkę z 40 dni.
Totalny absurd.

Na router, serwer, serwer plików jakieś emule, torrenty i coś tam jeszcze nadaje się jak najbardziej. Główna zaleta bardzo małe zapotrzebowanie na energię.

Obecnie nie liczę. Nie mam pojęcia. W pewnym okresie punktacja w tym projekcie zmieniała się dwa razy na tydzień.

Sugeruję tylko tyle, że ten proc nie nadaje się zbytnio do liczenia.

Na amd x2 4200 jestem w stanie przeliczyć przez 12h tyle co on będzie mielił w przeciągu miesiąca. XD

Cytat: Troll81 w 10 Lipiec 2009, 10:59
niektórzy nadal liczą :D btw jaki projekt dobrze pociągnie na amdk6 II 450?? ew na podobnej prędkości intelu??

Liczyłem przez około 3 miesiące na amdk6 II 500. Droga przez mękę. Nie obsługuje sse.

Dobrze wspominam jedynie okres w którym milka karmiła go tak samo jak najszybsze procki, czyli dawała po równo wszystkim 2500 punktów na rdzeń. XD Ba w chroocie kopilowało się jednocześnie gentoo.

Poźniej to się zmieniło i spadło do ok 100-130 punktów na dzień.
W enigmie był wstanie wyciągnąć 40-50 pkt. ;D

Można to nazwać fartem, choć 4 WU to prawie cały dzień liczenia.
Również jadę na 5.10.45, ale widzę, że takie błędy są również na hostach z  6.2.19, 6.4.5 i pewnie jeszcze innych.

Mam nadzieję, że bazy projektu zostaną przywrócone w 100% do stanu z przed awarii. Obecnie coś
jest nie w porządku. Sytuacja dotyczy próbek wysyłanych w krytycznym momencie, prawdopodobnie tuż
przed padem serwera. Chyba miałem niefarta i takie pobrałem.

CytatEinstein@Home 1 1245896101 Scheduler request succeeded: got 12 new tasks
Einstein@Home 2 1245896101 Message from server: Resent lost result h1_0726.60_S5R4__68_S5R5a_1
Einstein@Home 2 1245896101 Message from server: Resent lost result h1_0726.60_S5R4__67_S5R5a_0
...
Einstein@Home 2 1245896101 Message from server: Resent lost result h1_0726.60_S5R4__59_S5R5a_0
Einstein@Home 2 1245896101 Message from server: Resent lost result h1_0727.00_S5R4__309_S5R5a_2
Einstein@Home 1 1245896103 Started download of skygrid_0730Hz_S5R5.dat
Einstein@Home 1 1245896103 Started download of skygrid_0750Hz_S5R5.dat
1 1245896225 Project communication failed: attempting access to reference site
Einstein@Home 1 1245896225 Temporarily failed download of skygrid_0730Hz_S5R5.dat: http error
Einstein@Home 1 1245896225 Temporarily failed download of skygrid_0750Hz_S5R5.dat: http error
Einstein@Home 1 1245896225 Started download of h1_0727.05_S5R4
Einstein@Home 1 1245896225 Started download of l1_0727.05_S5R4
1 1245896228 Access to reference site succeeded - project servers may be temporarily down.
1 1245896347 Project communication failed: attempting access to reference site
Einstein@Home 1 1245896347 Temporarily failed download of h1_0727.05_S5R4: http error
Einstein@Home 1 1245896347 Started download of h1_0727.10_S5R4
1 1245896350 Access to reference site succeeded - project servers may be temporarily down.

Dziś po odesłaniu i zaraportowaniu status tych 12 WU był początkowo Validate error + unsent :o
Obecnie tylko 4 z nich mają Validate error, pozostałe się "naprawiły".

Odnoszę wrażenie iż wina leży całkowicie po stronie serwera. :(

Hej!

Nadpisz stare binarki nowszymi w starym katalogu lub druga propozycja z poprzedniej lokalizacji przekopiuj dwa kluczowe pliki client_state.xml i client_state_prev.xml do nowego katalogu.

Cytat: TJM w 06 Czerwiec 2009, 14:30
W nowszych wersjach kernela (chyba RC) jest to już podobno naprawione, tak coś mi się o oczy odbiło przy czytaniu jakiegoś changeloga.
Swoją drogą, 7h które zadania liczyło ? Wydaje się to dość długo nawet jak na AMD.

Siedzę na stosunkowo nowym kernelu 2.6.29.3

Zadania z serii p2030... liczą się ok 38000s, a oznaczone h1_... różnie od 18000 do 26000s, czyli baaardzo dłuuugo.

Wszystko wskazuje, że konfiguracja linuksowego kernela z 'CONFIG_PREEMPT=y' ma destrukcyjny wplyw na aplikację Einsteina. W dodatku generowany był złowieszczo brzmiący komunikat "FPU ... PRECISION INVALID".

Po przekompilowaniu kernela wszystko jest już ok. Szkoda tylko próbek, które wysypywały się po 7h liczenia. >:(

Cytat: TJM w 04 Czerwiec 2009, 15:24
Połączenie czegoś z wysoką kompresją z tarem jest fajne, tylko teraz trzeba jeszcze sortować po rozszerzeniach, a z tym już ciut gorzej, bo w jednym takim dużym katalogu do skompresowania może być ze 100 jak nie więcej różnych.

Szukanie po rozszerzeniach, rozmiarze, uprawnieniach, datach utworzenia - find cię wyręczy.

pliki tylko z roszerzeniem txt, pdf, doc
find /katalogi/do/archiwum/ -xdev -type f -regex '.*\.\(txt\|pdf\|doc\)$' -print0 | tar --null -T - -cvf - | 7za a -si -mx=9 /archiwum.txt.pdf.doc.tar.7z

ewentualnie -type f '(' -name '*.txt' -o -name '*.pdf' -name '*.doc' ')'

wszystkie oprócz plików z roszerzeniem txt, pdf, doc
find /katalogi/do/archiwum/ -xdev -type f ! -regex '.*\.\(txt\|pdf\|doc\)$' -print0 | tar --null -T - -cvf - | 7za a -si -mx=9 /archiwum.tar.7z

pliki tylko z roszerzeniem txt, pdf, doc i większe niż 10MB
find /katalogi/do/archiwum/ -xdev -size +10M -type f -regex '.*\.\(txt\|pdf\|doc\)$' -print0 | tar --null -T - -cvf - | 7za a -si -mx=9 /archiwum.tar.7z


z jednoczesnym kasowaniem
find /katalogi/do/archiwum/ -xdev -size +10M -type f -regex '.*\.\(txt\|pdf\|doc\)$' -print0 | tar --remove-files --null -T - -cvf - | 7za a -si -mx=9 /archiwum.tar.7z


SquashFS ma tą przewagę, że na podmontowanym woluminie masz bezpośredni dostęp do plików, ogromny atut.

Cytat: patyczak w 04 Czerwiec 2009, 00:18
Z POEM@home nie jest tak źle, u mnie każda próbka serii 417 zużywa 28MB z RAMu

O faktycznie jest ok. Dwie próbki jedna 16MB, druga 27MB.

Dziś dwie próbki rosetty wisiały sobie z 8h, aż się zorientowałem co jest grane. Swap cały zawalony.
Dopiero po restarcie boinca ruszyły.

przyjrzyj się uważnie SquashFS on pasuje jak ulał
http://www.tldp.org/HOWTO/SquashFS-HOWTO/creatingandusing.html
http://jakilinux.org/livecd/slax-i-nie-tylko-jak-to-dziala-na-pamieciach-usb/

7z + tar

tar cf - /tmp/test/*.{txt,pdf,html} | 7za a -si -mx=9 test.tar.7z

jeśli używasz Midnight Commandera to takie archiwa będą półprzezroczyste.

Może czas wyjść z ciemnych wieków kerneli 2.6.18 i troszkę poeksperymentować z czymś nowszym. :D
Są systemy plików z kompresją (całkowita przezroczystość).

Świetny jest reiser4 (bardzo dobra wydajność) co prawda nie ma go w głównej gałęzi kernela, ale to ze względów pozaformalnych. Współtwórca przebywa w więzieniu i to chyba z dożywociem.
Można spatchować kernel http://www.kernel.org/pub/linux/kernel/people/edward/reiser4/reiser4-for-2.6/

Obecie testuję btrfs (mój faworyt). Również umożliwia kompresję. Jest dostępny od 2.6.29.
Możliwości ma ogromne, wydajność dobrą.
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg02409.html

Umożliwia rozszerzanie, zmniejszania w locie, kompresję, tworzenia snapshotów, tworzenie raidów, optymalizację
dla dysków ssd i dużo więcej
http://btrfs.wiki.kernel.org/index.php/Main_Page#Documentation

Jest squashfs w połączeniu z aufs daje duże możliwości.
http://jakilinux.org/linux/slackware/slax-60-jak-to-dziala/


W konću lvm http://devrandom.pl/2008/12/lvm/

Kiedyś był E2compr już nierozwijany.

Oczywiście ze względów bezpieczeństwa wszystko można testować na pikopartycjach ich tworzenie, montowanie i zarządzanie jest banalnie proste.

Jajko już przekompilowałem, pozostaj ominąć limit wu i testować.
Choć już mój entuzjazm dla projektu minął, a to za sprawą beznadziejnej wydajności pod AMD. :(

Wydajność procków amd do intela ma się tak samo jak w przypadku primegrid (LLR) słabiutko.
Tu już tylko nowsze AMD II pewnie mogą dotrzymać kroku intelowi.
Chyba, że to wina słabej optymalizacji aplikacji.

Cytat: TJM w 04 Czerwiec 2009, 12:38

/proc/config.gz niestety u mnie nie istnieje.

Ponieważ kernel skonfigurowany bez 'Kernel .config support' ;D
Wszystkie nowsze tak się konfiguruje. Po prostu jest to bardzo wygodne w każdej chwili można sprawdzić jak
jest skonfigurowane jajko, które kompilowało się 3 lata temu, a config się gdzieś już zapodział.

.config o ile masz źródła powinien być tu
/lib/modules/2.6.xx/~build/.config

W twoim przypadku raczej i tak jest '# CONFIG_PREEMPT is not set'

Pobrałem mprime http://www.mersenne.org/freesoft/
i zapuściłem na 6h (krótko?) torture test. Przy taktowaniu 2650 nie wykazał żadnych błędów.
Z prockiem raczej wszystko ok.

Mam prośbę do osób liczących pod linuksem, którym aplikacja nie sprawia żadnych problemów, aby sprawdziły config kernela. Chciałbym się dowiedzieć czy problem aby nie dotyczył kerneli skopilowanych z

Preemptible Kernel (Low-Latency Desktop) - YES

Bardzo łatwo to sprawdzić

zgrep 'CONFIG_PREEMPT=y' /proc/config.gz

Trudno mi jednoznacznie to wykluczyć, ponieważ obecnie mój dzienny limit WU = 2.

na youtube znalazłem taką perełkę (cover) z antypodów
http://www.youtube.com/watch?v=9PGKjPgbTt4
tu orginał
http://www.youtube.com/watch?v=4dMfnGIiQQ8&feature=related

i coś z innego bieguna muzycznego, polecam najnowszą płytę Mastodon - Crack the Skye

To jest lekkie przegięcie z tą zachłannością na RAM.
Właśnie przeliczam dwie próbki z serii lb_dk_ksync__full_hb...
Zeżarły 720MB. :o W kompie mam 1GB. Odpalony firefox i praktycznie nic już nie zostaje...

i weź tu licz biologiczne projekty.

O ile sobie przypominam to poem jest równie zasobożerny.

Może to problem programowy. Już wczoraj chciałem sprawdzić to pod innym kernelem i inną dystrybucją.
Tylko na dzień dobry, boinc wysypał wszystkie próbki.
Dystrybuowane aplikacje einsteina (i686) są linkowane dynamicznie i pod architekturą x86_64 wymagają podstawowych bibliotek 32-bit, których nie miałem. Cały dzienny limit wu został wyczerpany.
Ewentualnie przekompiluję obecny kernel z CONFIG_PREEMPT=n.

Taki primegrid (LLR) liczył poprawnie przy taktowaniu 2650. Wydawało mi się, iż jest to dość dobry test stabilności.

Przestawiłem boinca na projekt miesiąca i mam nie lada problemy. Mianowice ok 40-50% próbek wywala się.

CytatFPU status word ffff88e1, flags:  ERR_SUMM STACK_FAULT PRECISION INVALID

Procesor to AMD Athlon 64 X2 4200. Na co dzień pracuje stabilnie z częstotliwością 2700-2750MHz.
Z powodu błedów zmniejszałem taktowanie, aż doszedłem do nominalnego - 2200 i o dziwo, i w tym wypadku
częstość błędów jest identyczna jak przy znacznym OC.

Nigdy wcześniej nie robiłem żadnych stress testów ani memtestów ponieważ nie było takiej potrzeby, komp
pracował stabilnie.
Czyżby procek już swoje wysłużył i był uszkodzony? Jak go dobrze przetestować?

Rad-Poland pomysł z kumulowaniem głosów jest ok.
Nie ma nic przeciwko liczeniu projektów mniej popularnych.
Ba zależy mi aby jak najwięcej osób angażowało się w liczenie projektu miesiąca. Obecnie wielka piątka
generuje z 50% punktów, a srednia ilość osób liczących to raptem troszkę ponad 100. Malutko.

Ja bym optował za rozwiązaniem podanym przez Piga. Naturalnym wydaje się być, że jeśli oddaję głos,
to biorę w tym aktywny udział. Oczywiście na miarę swoich możliwości, oddając symboliczną część mocy obliczeniowej projektom mniej lubianym.

Dziwaczną zaś sytuacją jest udział w głosowaniu, ale w zabawie już nie. Głosuję przez 12 miesiecy zaś, ani razu
nie liczę zwycięskiego projektu.
Równie dobrze mógłbym założyć konto w teamie BOINC Synergy i decydować co oni mają liczyć.

Demokracja demokracją, ale aby głosować należy mieć ukończone 18 lat.
Absolutnie jestem za weryfikacją.
Przeciez to zakrawa na farsę, aby akceptowane były głosy z lewych kont bez żadnego wkładu w dorobek punktowy zespołu.

głos na Einsteina

Ja tylko dorzucę prosty sposób na zabezpieczenie się przed uwalaniem WU.
Przy wszelkich eksperymentach wyłączyć całkowicie aktywność sieciową w managerze.
Robisz backup. Jeśli coś idzie nie tak, manager nie ma możliwości poinformowania o tym serwera,
a ty spokojnie przywracasz backup i kombinujesz dalej.

W stosunku do defaultowej aplikacji, pewnie o minimum 30%.
Wystarczy przetestować. Miarodajny benchmark jest tu:
http://tjm.boo.pl/enigma/eb.tgz

Ja wczoraj z ciekawości zainstalowalem wersję 32-bit pod qemu z KVM i byłem zaskoczony.

Czas instalacji ok 20 minut - jak na wirtualny dysk całkiem szybko. Żadnych problemów. Wszystko działa w miarę.
No może oprócz pasjansa, bo ten chyba wymaga akceleracji ;D. Przez vnc, karty przesuwają się w żółwim tempie.
Pamięci niestety zbyt wiele w kompie nie mam tylko 1GB i co mogłem 768MB oddałem win7.
Jedna rzecz mnie cholernie denerwuje - wszystko bardzo rozmyte, mało ostre. Nie da się tego zmienić (monitor CRT).
Czas uruchamiania to ok 50s.

Ewentualnie jeśli ktoś się jeszcze bardzo obawia o swoje dane na dysku, to można spróbować tak:
http://wss.pl/Articles/10516.aspx

Cytat: TJM w 18 Maj 2009, 20:33
Buninek, pisałeś wcześniej że testowałeś Open64 - mógłbyś spróbować zbudować aplikacje dla Intela (najbardziej interesuje mnie taka pod Wolfdale, czyli chyba SSE 4.1) ?

Możesz przetestować tą, ale pewnie nadzwyczajnie szybka to nie jest.
enigma.xeon.x86_64

Przy wolfdale pluje:

Cytatopencc ERROR: Target processor does not support SSE2.

:o

W sumie to pod większość procków skopilował exeki i zamieścił na forum,
gość podpisujący się jako mdoerner
http://members.cox.net/mdoerner1/enigma_0.76_i686-pc-linux-gnu_optimized-Linux.tar.gz

Ja bym sugerował zwrócenie się z prośbą o pomoc na jakąś grupę dyskusyjną np. pl.comp.os.linux.
Bywają tam osoby, które na codzień mają do czynienia w zarządzaniu serwerami z odpowiednim doświadczeniem i wiedzy.

Iotop fajnie monitoruje i pokazuje pid-y procesów.
Co się dzieje z pamięcią (free) i swapem w tych krytycznych momentach (bardzo wysoki %wa)?

Możesz poczytać o vm.swappiness. Jego zwiększenie zmniejszyłoby ilość I/O.
http://www.linuxvox.com/linux-articles/kernel-tuning/1-what-is-the-linux-kernel-parameter-vm-swappiness

Cytat: TJM w 14 Maj 2009, 22:56
Serwer mnie ostatnio denerwuje, coś się kaszani ale nie jestem w stanie wyczaić jeszcze co i dlaczego.
Podczas normalnej pracy jakoś sobie chodzi, ale bywa, że nagle wskakują mu np. takie statsy na czasie procesora:

0.2%ni,  0.2%id, 61.6%wa,  0.1%hi,  0.9%si,  0.0%st

wtedy load od razu rośnie astronomicznie do wartości 10+ i np. scheduler przestaje odpowiadać (internal server error).
Domyślam się, że te 60+% waiting to czekanie na I/O, więc chyba dyski. Wydaje mi się, że to chyba stary dysk IDE na którym są różne pliki i katalog upload powoduje takie zachowanie, chociaż nie mam na to dowodów i nie wiem jak je zebrać.

Może iotop lub iostat cokolwiek rozjaśnią sytuację?

Sprawdzałem ją na czterch różnych systemach - dwóch x86 i  x86_64 - działała. Skompilowałem natywną wersję x86.

Nic tylko trzymać kciuki za sprawną pracę serwera. Przeżywa trudne dni, a ty zbierasz
nie małe doświadzczenie próbując go ujarzmić. :)

Może zamiast symlinków lepszym rozwiązaniem będzie bindowanie.

http://groups.google.pl/group/pl.comp.os.linux/msg/cd71756222edddcd

Sprawdź jeszcze czy przy optymalce jest

<platform_name>anonymous</platform_name>

w pliku sched_request_www.enigmaathome.net.xml

Przypadkiem nie ładujesz na siłę optymalki bez odpowiedniego app_info.xml.

Cytat: Troll81 w 08 Maj 2009, 10:13
dziś ok 9:30 aktualizowałem chyba ze dwa razy a teraz jestem w roboci. Jak wrócę to znów poaktualizuję.

A jak nie będzie działać to 6.5.0 zainstaluję

Czy w client_state.xml i client_state_prev.xml masz poprawne adresy schedulera?

<scheduler_url>http://www.enigmaathome.net/enigma_cgi/cgi</scheduler_url>

Jako mało wymagający liczydłowy (liczę głównie jeden projekt i nie korzystam z GPU), nie zauważyłem wielkich różnic pomiędzy rożnymi wersjami managerów.
Obecnie jadę na 6.6.25. Jedyny minus to zwiększony apetyt na RAM. W 24h od startu pożarł 25MB. Przy starcie 5MB. Trzeba powrócić do poprzedniego.

Katalog boincowy jest ciągle ten sam. Pliki time_stats_log oraz job_log_boinc* zawierają całą historię mojego liczenia.