http://boinc.almeregrid.nl/
MOżna już zakładac konta. I dopinać sią na boincstats
założone i dołączone ;D
ale to już było ;)
http://www.boincatpoland.org/smf/index.php/topic,1560.0.html
a to Troll ;D
sorki Troll to jednak inny projekt - tamten to testowy AlmereGrid
konto założone
ale skucha ::)
bo trza trollowi ufać :D uf uf
Co to griduje? :P
Almery jak nazwa wskazuje :D
Z ciekawości się podłączyłem, jest wielka lipa: zadania startują ale czas CPU stoi na 0, nic się nie dzieje tylko w kółko uruchamiane są jakieś procesy. Po chwili zaczyna zamulać managera, tak że ostatecznie ledwo się ich pozbyłem.
liczy tak samo jak w projekcie testowym Almere w którym doliczyłem 2k pkt
obciążenie 15-18% CPU na próbkę + duże obciążenie systemu plików (w końcu zakłada setki/tysiąse plików)
projekt nadaje się do liczenia jedynie na VM z dużym buforem pamięci dysku ze względu na straty mocy obliczeniowej,
obecnie w AlmereGrid i AlmereGrid Test liczę po 5 wu na raz (ilość zależy od mocy CPU) i tak nieco mocy zostaje na rdzeniu, przy większej ilości wu rzuca błędami
co do czasu to faktycznie stoi początkowo na 0, następnie zwiększa się o 1sek na 1min przy 32/35sek kończy się przeliczanie wu (100%) a czas zostaje skorygowany na ok 8-9 minut
może by warto zrobić tabelkę z projektami które opłaca się liczyć na maszynach wirtualnych. Bo to by pomogło zwiększyć RAC drużyny
generalnie to chyba tylko AlmereGrid, AlmereGrid Test, UH Second Computing i DepSpid
licząc na VM zawsze tracimy pewną moc 1-3% ,niektórych projektów w ogóle nie opłaca się liczyć na VM czasy przeliczeń są kilka razy dłuższe niż na natywnej maszynie (np Hydrogen)
ja nie mam wyboru (główny system Linux64) i na VM liczę projekty które są tylko pod Windą lub projekty których wersje windowsowe są szybsze SHA i Spinhenge (używam do tego celu triali/RC MS 2003Server obecnie 2008 Server jest o kilka procent wydajniejszy i może sobie siedzieć 240 dni)
co do wielkości RAC zespołu to niewielki by to miało wpływ, ewenementem jest projekt GPUGrid w którym podejmowane były próby wykorzystania niewykorzystanej mocy rdzenia współpracującego z GPU (w innym temacie)
generalnie VM są przydatne do przechwytywania większej ilości wu w projektach okresowych (np: LHC), a w DepSpid do odseparowania sieci (przynajmniej tak mi się wydaje)
dodam tylko, że DepSpid jest nieaktywny (łącznie z www) od nastu miesięcy i na zmianę się nie zanosi
A jednak mylisz się, depspid ma teraz drugi podprojekt (na razie zamknięte testy) gdzie przygotowywane są nowe aplikacje. Osatnia seria zadań dla głównego projektu była może 3-4 miesiące wstecz (nie pamiętam dokładnej daty).
ok - cofam - na zmianę się zanosi :-[
projekt będzie działał podobnie do poprzedniego? wróci pod tą samą nazwą na boincstats? no i czy mają inne www? bo tamto od dawna nie działa :(
na VM można również liczyć Pirates@Home - gdyż wymaga nowych często testowych wersji Managera Boinc niekoniecznie stabilnych/ odpowiednich dla głównego systemu
EDIT: Depspid - główna strona projektu/forum ok http://depspid.bjoernhenke.de/
hmm a ja od roku usiłuję wbić na http://depspid.dyndns.org/orig/home.php |-? :-[
ten nowy adres jest za razem adresem przy dołączaniu do projektu, czy na starym również zadziała?
adres to www.depspid.net i innego nie powinno się używać ze względu na problemy z dynamicznym IP.
Podłączać się nie ma co na razie, bo serwer leży od jakiegoś czasu ze względu na pad hardware.
poza tym ktoś wspomniał o zamknietych testach??
Cytat: Troll81 w 22 Październik 2008, 10:03
może by warto zrobić tabelkę z projektami które opłaca się liczyć na maszynach wirtualnych. Bo to by pomogło zwiększyć RAC drużyny
Trollu czasami ci sie uda cos madrego wymyslec. uwazam ze to dobry pomysl.
Całkiem sporo niezłych pomysłów miewam. Ale wiesz ... myślenie strasznie boli. Dlatego wolę nie myśleć. XD
Przygladnalem sie blizej temu projektowi, korzystajac z zachety TJM (i poznania flagi noncpu :)). Biorac pod uwage jak ten projekt zajezdza HDD nie polecam nikomu, kto nie ma BOINC`a na RAMdysku (badz czyms podobnym). W ramach testu odpalilem projekt na 3xHDD 7200 SATA II NCQ w/RAID 0. Przy 5-ciu WU jeszcze wszystko bylo ok, ale powyzej 5-ciu WU na raz Warcraft mi sie przycinal :P (w ramach porownania 50WU FreeHAL`a na raz nie przeszkadzalo mi w niczym ;D). Projekt punktuje bardzo, bardzo slabo i albo zajmuje CPU, albo przy uzyciu flagi noncpu zajezdza HDD i to nawet HDD z NCQ (szkoda twardzieli).
Jak tylko bede mial jakis wolny dzien, to przetestuje ten projekt na i-RAM`ach (dla niewtajemniczonych - odpowiednik RAMdysku). Sadze ze korzystajac z RAMdysku mozna troche zaszalec w tym projekcie :). Generalnie widze tylko jeden powod liczenia tutaj. Poniewaz projekt zajezdza HDD i zajmuje CPU, to malo kto w nim liczy - najlepszy ma zaledwie 8k pkt! Zatem mozna latwo zostac gwiazda ;D. Nie powinno byc trudno zdobyc krolewski tron, nawet w statystykach swiatowych XD. I to jest dobry powod do liczenia :arrr:
Ja wymyśliłem coś takiego, że odpalę linuksa na 128MB Flashdrive na starym kompie z 1,5GB SDRAM, instalnę tam BOINCa żeby sobie coś przeliczał i jednocześnie ustawię RAMdisk który następnie udostępnię w sieci na potrzeby testów z almere.
testy wykonane
1) klasyczny HDD
- głośna praca dysku (zwłaszcza przy większej ilości próbek, trochę łagodzą duże bufory dyskowe)
= czas pracy CPU ok 490 sek/wu
dynamiczny RAM-Dysk
mount -t ramfs /dev/ram0 /home/xxx/.VirtualBox/RAM-Dysk
2) udostępniony Windzie uruchomionej na VM w trybie współdzielonego katalogu net use X: \\vboxsvr\RAM-Dysk
+ cisza
- wolna obsługa takiego katalogu (bardzo duże obciążenie systemu)
- jedna wu zabiera ok 70MB RAM-Dysku (10MB dane wejściowe + 57MB (40MB dane przeliczane + straty systemu plików, ponad 5400 plików))
- długi czas przetwarzania próbki (padła podczas weryfikacji)
3) udostępniony Windzie uruchomionej na VM z partycją NTFS 4k
+ cisza
+ duża szybkość systemu plików (obciążenie systemu podobne co w punkcie 1)
- jedna wu zabiera ok 70MB RAM-Dysku (10MB dane wejściowe + 57MB (40MB dane przeliczane + straty systemu plików, ponad 5400 plików))
= czas pracy CPU ok 480 sek/wu
EDIT: może inny klaster lub FAT32 zastosowany na partycji dałby lepsze wyniki,
ale system punktowy tego nie uwzględnia, oparty jest o benchmark i czas pracy nad próbką (ale w końcu cisza) :ph34r:
Hm dziwne. Powiadasz, że katalog udostępniony przez sieć działał bardzo wolno ? U mnie zasadniczo katalogi udostępnione w sieci (gigabit ethernet) z linuksowej macierzy RAID działają szybciej od lokalnego dysku, chociaż przy dużej ilości małych plików nie sprawdzałem. RAMdisk powinien być jeszcze szybszy.
Ja w almareGrid BoincGrid mam 14,07 punkta a w test Grid 59,36 i nie jestem najlepszy??
Cytat: TJM w 11 Listopad 2008, 22:48
Hm dziwne. Powiadasz, że katalog udostępniony przez sieć działał bardzo wolno ?
to udostępnienie katalogu od strony Windowsa wygląda jak przez sieć, ale w rzeczywistości jest to udostępnione przez wtyczkę/sterownik VirtualBox'a (i w nim jest problem z wydajnością) - Windowsa posiadam tylko na VM (Windows serwer 2008 RCx - trial 240 dni)
Na ramdysk można rownież wykorzystać bardzo szybką pamięć kart graficznych.
Niestety nie na kartch nvidii. Jeśli dysponujesz kartą ati z 256MB lub 512MB warto spróbować.
http://hedera.linuxnews.pl/_news/2002/09/04/_lite/1449.html (http://hedera.linuxnews.pl/_news/2002/09/04/_lite/1449.html)
Widzę, że niedobrze wpływa na zadania ich wstrzymywanie gdzieś w środku, liczą się później dalej ale na koniec wyskakuje compute error. Wstrzymywanie na początku (w celu zabawy z przełączaniem non_cpu_intensive/cpu_intensive) nie ma takiego wpływu.
http://boinc.almeregrid.nl/top_teams.php?sort_by=total_credit
Najlepszy team ma tylko 7k punktów - moglibyśmy łatwo przejąć pierwsze miejsce.
I takoz zrobimy :). Juz niedlugo.
Atak na jakiekolwiek pierwsze miejsce będzie jednak trudniejszy niż myślałem. To dlatego, że zadań w projekcie cosik maławo i ciężko dorwać kilkadziesiąt na raz do późniejszego równoległego przetwarzania. Jak się pojawiają, zazwyczaj udaje mi się zassać tylko z 20-30 bo ściągają się bardzo wolno (mają po kilka MB).
Zostawienie jako non_cpu_intensive żeby sobie ściągało po jednym też nie działa wcale lepiej, bo przez 3/4 czasu nie ma żadnego.
Testów ciąg dalszy: karta CF wpięta do kompa z linuksem na pokładzie, system plików ReiserFS udostępniony windowsowi klasycznie przez otoczenie sieciowe, zmapowany dysk sieciowy, sieć gigabit ethernet. Szału nie ma, transfer liniowy sięga ledwo kilka MB/s, ale zadania Almere przeliczają się dużo szybciej.
Niestety zauważyłem w tym projekcie coś bardzo negatywnego: niezależnie od nośnika na którym wszystko się znajduje, od czasu do czasu zdarzają się dłuższe lub krótsze momenty kiedy Almere tak obciąża system, że 98% czasu procesora/procesorów wciąga proces bezczynności. Zazwyczaj na poczatku i na końcu każdego WU, co przy odpalonych kilku WU na raz zdarza się dość często powodując spadek wydajności liczenia innych projektów.
Cytat: TJM w 20 Listopad 2008, 14:09
Testów ciąg dalszy: karta CF wpięta do kompa z linuksem na pokładzie, system plików ReiserFS udostępniony windowsowi klasycznie przez otoczenie sieciowe, zmapowany dysk sieciowy, sieć gigabit ethernet. Szału nie ma, transfer liniowy sięga ledwo kilka MB/s, ale zadania Almere przeliczają się dużo szybciej.
Niestety zauważyłem w tym projekcie coś bardzo negatywnego: niezależnie od nośnika na którym wszystko się znajduje, od czasu do czasu zdarzają się dłuższe lub krótsze momenty kiedy Almere tak obciąża system, że 98% czasu procesora/procesorów wciąga proces bezczynności. Zazwyczaj na poczatku i na końcu każdego WU, co przy odpalonych kilku WU na raz zdarza się dość często powodując spadek wydajności liczenia innych projektów.
A na jakim kompie probowales (proc/mem)? Moze sie okazac ze na odpowiednio szybkim (quad 3-4GHz, 4GB szybkiej mem) kompie cos takiego nie bedzie mialo miejsca.
E7200 3,5GHz, 2GB DDR2/1200. Hardware nie ma tu nic do rzeczy, sam system powoduje takie dziwne zjawisko, proc nagle zostaje bez obciążenia prawdopodobnie non stop czekając na wyniki operacji I/O.
No to juz mnie bardzo dziwi. Dziwi mnie bo przeciez odpalales Almere na RAMdysku. A na RAMdysku ilosc operacji I/O jest o wiele, wiele wyzsza niz w przypadku normalnego HDD... Wiec na wynik I/O nie powinienes w tym przypadku czekac...
Na RAMdisku też to występowało ale na znacznie mniejszą skalę.
EDIT: Trafiłem na zadanie które za każdym razem przy uruchomieniu wyłączało mi kompa. Nie wiem jak to możliwe, ale miałem ogromny zacier żeby się go pozbyć, dopiero przy którejś z rzędu próbie kliknięcia na snooze przy starcie managera udało mi się przejąć kontrolę.
też miałem takie zadania (dwie sztuki) VM z Windows Serwer 2008 - wylatywał w kosmos
- pomogło jedynie ręczne zablokowanie zadań,
- co ciekawe to był też problem ze skasowaniem plików, które powstały podczas przetwarzania tych próbek.
Hm zastanawiało mnie czemu ten projekt zamula kompa, zacząłem analizować więc zawartość workunitów. Cargocaptain to nic innego jak klasyczny wrapper, który odpala kilka (kilkanaście?) tysięcy zadań w czasie pracy. Każde trwa max tylko kilka sekund, a na szybkich kompach mniej niż sekundę. Pewnie to tworzenie i zamykanie procesów zamula tak system, i można się spodziewać, że im szybszy nośnik tym efekt będzie bardziej widoczny. A wystarczyłoby dodać odpowiednik sleep(5) między odpaleniami kolejnych zadań i workunity pewnie liczyłyby się 5 razy dłużej, ale za to spokojnie projekt mógłby być liczony przez większą liczbę osób jako non_cpu_intensive, bez nadmiernego mulenia.
Zastanawiam się, czy projekt łyknie anonymous platformę aka app_info - można byłoby zastąpić wszystkie jego exeki wrapperami które na początku odpalają sleepa np. na 5s a dopiero później właściwe polecenie (o zmienionej nazwie), wtedy byłoby wolniej ale bezpieczniej dla systemu. Co więcej, można by się pokusić o jeszcze lepsze rozwiązanie - przechowywanie plików na malutkim, parunastomegabajtowym RAMdisku zamiast w katalogu slot - to by jeszcze bardziej przyspieszyło działanie.
A moze biorac pod uwage Twoje swietne pomysly po prostu napisalbys do tworcow projeku? Ja tam mam o wiele mniejsza wiedze w tym zakresie od Ciebie, ale w GPUGrid udzielam sie jak tylko moge :).
Szczerze mówiąc, to nie chce mi się, z kilku powodów:
1) mój angielski jest za cińki, może bym się z nimi dogadał ale nie lubię nadużywać języka którym nie umiem się posługiwać
2) projekt nie ma żadnego forum gdzie można by coś zaproponować, a pisanie PMów do kolesi, co do których nawet nie wiadomo czy kumają coś po angielsku jakoś mi się nie uśmiecha
3) nie mam czasu ani zbytnich chęci, żeby zgłębiać się bardziej w zasadę działania ich aplikacji, to co wydaje mi się grubym błędem (błędami) może okazać się konieczne i nie do rozwiązania w inny sposób.
Btw, po rozpakowaniu ściągniętych archiwów, w katalogu z workunitem jest 1800 plików .dat które nie są do niczego potrzebne (przynajmniej w WU które widziałem, może są różne rodzaje) - skasowanie ich skraca nieco czas przeliczania WU, ponieważ czas potrzebny na przeglądnięcie katalogu się skraca, ale szału nie ma i różnica jest ledwo dostrzegalna.
Wreszcie odpalilem jednego kompa z BOINC`em na i-RAM`ie. Chcialem potestowac Almere, ale niestety mam klopot. Niezaleznie czy uzywam noncpuintensive czy nie, zawsze wyglada to u mnie tak:
11/28/2008 10:10:17 AM|AlmereGrid Boinc Grid|Sending scheduler request: To fetch work. Requesting 2300903 seconds of work, reporting 0 completed tasks
11/28/2008 10:10:22 AM|AlmereGrid Boinc Grid|Scheduler request failed: Error 403
11/28/2008 10:10:22 AM|AlmereGrid Boinc Grid|Sending scheduler request: To fetch work. Requesting 2300903 seconds of work, reporting 0 completed tasks
11/28/2008 10:10:27 AM|AlmereGrid Boinc Grid|Scheduler request completed: got 0 new tasks
I za nic nie wiem co z tym zrobic. Wczesniej nigdy mi sie to nie zdarzalo - czy moze ktos cos doradzi?
EDIT: no dobra, najpierw nalezy czytac...:
Werkt nu compleet. U kunt u aanmelden om de wetenschap een handje te helpen.
To chyba znaczy ze sie praca skonczyla (moze ktos potwierdzic? czy ktos wciaz otrzymuje WU?). Ale drugiego zdania, to juz ni cholery ;)
Przerwy w dostawie WU to standard, czasami przez cały dzień brakowało. Ja jeszcze parę godzin temu jakieś miałem, teraz też nic.
Cytat: TJM w 28 Listopad 2008, 10:53
Przerwy w dostawie WU to standard, czasami przez cały dzień brakowało. Ja jeszcze parę godzin temu jakieś miałem, teraz też nic.
1. Dalej wali bledami.
2. pobralo jakies 60 WU (dalej walac bledami XD).
3. O ile dobrze pamietam, to error 403 to jest chyba service_unavailable. Mam racje?
4. Odpale 20 taskow na dobry poczatek - zobaczymy efekty (a co, od razu z hardcore`a ;D).
403 = forbidden. W almere to standard, mają dwa scheduler URLe (prawdopodobnie projekt podzielony na wiele serwerów) z czego pierwszy nigdy nie działa i dopiero przy drugim requeście się udaje.
Mi przed chwilą projekt znów wyłączył kompa, nieźle to wkurzające >:(
Jak projekt mógł ci wyłączyć kompa????
Bo to jest projekt o przejecie wladzy nad swiatem :P XD
EDIT:
No, i-RAM`y rzadza ;D. Jak tak dalej pojdzie, to moment i pierwsze miejsce moje :attack: (pod warunkiem ze serwer nadarzy WU produkowac). WU przeliczyly sie blyskawicznie - ani nie zauwazylem kiedy.
Podczas liczenia jednoczesnie 20 WU Disk usage wynosil:
Min Disk usage: 2%
Max Disk usage: 37%
Average Disk usage: 5%
Niestety, proba odpalenia na raz 48 WU (eksperymentalnie oczywiscie :P) spowodowala brak miejsca na czterogigabajtowym i-RAM`ie po 1 minucie :P. Musze obczaic jaka maksymalna ilosc WU na raz moge puscic.
Normalnie, niektóre zadania mają coś zwalone i wyłączają kompa lub w lżejszym przypadku tylko wywalają samego managera. Jak trafisz na takie zadanie, to zacier jest się go pozbyć, jeżeli samo się nie wykrzaczy. Ja miałem BOINCa w autostarcie i nawet nie mogłem przez to normalnie uruchomić, bo zanim na dobre się pulpit pojawił już się wyłączał XD
miałem podobne przypadki, ale AlmereGrid mam uruchomione na trzecim Boinc w dodatku pracującym na VM z jedną partycją RAM-dysk nawet jak coś się sypnie i wyleci Boinc lub cały system na VM (nawet Win2008serwer się resetuje - na razie 2 razy), pozostałe managery liczą
Cytat: AiDec w 28 Listopad 2008, 15:21
No, i-RAM`y rzadza ;D. Jak tak dalej pojdzie, to moment i pierwsze miejsce moje :attack: (pod warunkiem ze serwer nadarzy WU produkowac). WU przeliczyly sie blyskawicznie - ani nie zauwazylem kiedy.
pierwsze miejsce czeka - brakuje Tobie niecałe 600 pkt
niestety nie mogę liczyć więcej niż 5wu jednocześnie na rdzeń czyli łącznie 10wu (po przekroczeniu tego limitu wu sypią errorami całymi seriami próbek :(
natomiast uruchomienie większej ilości BM z większą ilością wu powoduje wydłużenie liczenia próbki i wpadam w pułapkę CPU-maksimum time (w końcu punktacja oparta jest o benchmark BM)
z przeliczeń teoretycznych wynika, że maksa jaki mogę wycisnąć z tego projektu to 70pkt/h
tak więc
AiDec możesz wyliczyć kiedy obejmiesz 1 miejsce :attack:
chyba sobie sprawię te iRAmy :D
Cytat: RAD-Poland w 28 Listopad 2008, 16:29
tak więc AiDec możesz wyliczyć kiedy obejmiesz 1 miejsce :attack:
24h :P :attack:
Cytat: Troll81 w 28 Listopad 2008, 17:36
chyba sobie sprawię te iRAmy :D
Spraw sobie. Bardzo polecam. I kilku innym osobom tez. Sa lekko klopotliwe (jak to nietypowe twardziele), ale maskaruja wydajnosciowo wszystkie inne rozwiazania. Jedynie Fusion IO moze do tego podskoczyc, ale i tak nie we wszystkich zastosowaniach. Dobrze wykorzystany i-RAM to potega. Szkoda tylko ze najlepsze z nich, i-RAM BOX`y sa niedostepne :(.
idzie to w pl kupić?
w pl nie kupisz :(
zostaje tylko ebay
może urządzimy sobie jakieś teamowe zakupy? ktoś by sprowadził?
Nic nie musisz sprowadzac - kupujesz na ebay`u, a przesylka przychodzi poczta lub kurierem.
40WU Almere na raz. Plus oczywiscie full load PrimeGrid. Plus oczywiscie GPUGrid. Plus FreeHAL. Komp chodzi plynnie - nawet nie czuje tego Almere :). A wszystko tylko dzieki wpieciu na szybko jednego i-RAM`a. To tylko i-RAM albo Fusion IO potrafia :).
W PL na luzie się kupi, podejrzewam że w każdej hurtowni oferującej sprzęt gigabyte. Ja już się dowiadywałem i jest możliwość sprowadzenia, niestety czas oczekiwania na zamówiony towar w tym przypadku co najmniej 3-4 tygodnie i cena wychodzi mało atrakcyjna w porównaniu z zagranicznymi sklepami/aukcjami.
Cytat: TJM w 29 Listopad 2008, 02:19
W PL na luzie się kupi, podejrzewam że w każdej hurtowni oferującej sprzęt gigabyte. Ja już się dowiadywałem i jest możliwość sprowadzenia, niestety czas oczekiwania na zamówiony towar w tym przypadku co najmniej 3-4 tygodnie i cena wychodzi mało atrakcyjna w porównaniu z zagranicznymi sklepami/aukcjami.
To moze dowiedzialbys sie o i-RAM BOX`y? Ja bym bardzo chetnie zamowil, gdybym tylko mial gdzie... A wtedy i-RAM`y bylyby mi drogi kolego zbedne jesli mnie rozumiesz ;).
EDIT:
RAD: 24h nie wystarcza zeby Cie wyliczyc, skoro WU nie ma :(.
BOXy są nieosiągalne, ponoć nawet zwykłe iRAMy nie są w ogóle w sprzedaży w Polsce, hurtownie nie mają ich w ofercie i stąd trzeba na głowie stawać, żeby je dostać. Chociaż spróbuję zapytać jeszcze znajomego pracującego w pewnym sklepie w Łodzi, już raz załatwił mi sprzęt, którego nigdzie indziej nie było.
Są jakieś przyspieszenia w samym czasie przeliczania WU na iRAMach ? Z moich zgrubnych pomiarów i obliczeń pi razy drzwi wynikało, że zastosowanie jakiegokolwiek nośnika o krótkim czasie dostępu skraca czas o około 20%, nieważne czy jest to RAMdisk czy bufor plikowy sieciowego systemu plików czy też CF-Flashdrive.
Na jakim OSie odpalasz Almery ? U mnie na XP 32bit system przymula od samego uruchamiania setek progsów jeden po drugim, pewnie dlatego, że wrapper odpala je w '16 bit mode'. Aż kusi mnie, żeby zrobić app info i spróbować zmienić to na 32bit.
Jesli chodzi o i-RAM`y to ja ich widze w okolicy na potege. A jakby doliczyc ebaya i inne takie, to moglbym tysiac od reki kupic. Ale i-RAM BOXow to nawet na zamowienie nie moge dorwac, mimo ze oferuje 100% przebitke :/.
Przyspieszenia przeliczania na i-RAMach nie zauwazylem, ale tez fakt ze sie nie przygladalem. W kazdym razie nie rzucilo mi sie jakos w oczy. Ale pamietaj ze u mnie caly system stoi na `pamieciach` wiec wszystko chodzi tak cholernie szybko, ze mnie to juz nic nie dziwi :P. Anyway przyspieszenia nie stwierdzam, ale nie w tym celu ten sprzet kupowalem ;). Tobie tez i-RAMy polecalbym do innych niz `liczenie` zastosowan (serwer bazodanowy np.) :).
EDIT: Przepraszam TJM. Nie doczytalem Twojego pytania. Almery odpalam na XP32 SP3 i X64 SP2.
Dodatkowe info:
Moge odpalic max 20 WU Almere na raz i przeliczyc wszystkie w 100% bezblednie. Przy wiekszej ilosci (na raz) pojawiaja sie bledy. Ciekaw jestem czy ktoremus z Was udalo sie odpalic ponad 20 WU na raz (25, 30, 40?) i przeliczyc wszystkie w 100% bezblednie? Moze na klasycznym HDD byloby to mozliwe, aczkolwiek zalecam tylko jedna probe (no chyba ze ktos chce zajezdzic HDD :P) - bylbym wdzieczny gdyby ktos mogl taka probe wykonac (odpalic 40 Almerow na noc...?). Anyway i-RAM`y w tej konkurencji poprostu miazdza. Nawet odpalajac na probe 45 WU na raz (wiedzialem ze polowa sie wysypie, ale eksperyment trzeba bylo zrobic :) ) nie zauwazylem ZADNEGO spowolnienia dzialania kompa (wciaz gralem plynnie w Crysisa przy 45 Almerach). Wyglada na to, ze nawet 45 Almerow nie jest w stanie `wygenerowac` tyle polecen zapisu/tworzenia plikow, zeby jeden i-RAM (testowane na JEDNYM i-RAM`ie!) nie byl w stanie sobie z tym poradzic.
Cytat: TJM w 01 Grudzień 2008, 01:13
Na jakim OSie odpalasz Almery ? U mnie na XP 32bit system przymula od samego uruchamiania setek progsów jeden po drugim, pewnie dlatego, że wrapper odpala je w '16 bit mode'. Aż kusi mnie, żeby zrobić app info i spróbować zmienić to na 32bit.
Wszystko wskazuje mi zatem na to, ze przyczyna lezy tylko i wylacznie po stronie `klasycznego` HDD w Twoim przypadku. I chyba dojdziesz to tego samego wniosku po przeczytaniu moich powyzszych informacji.
Ale ja nie używam klasycznego hdd tylko karty CF na IDE, transfery z tego są na poziomie starszych HDD ale random access time bez porównania lepszy.
Przez samo uruchamianie dużej liczby procesów większość czasu procesora przejmuje u mnie proces bezczynności systemowej, do tego stopnia, że z odpalonymi 4-5 almere żadne inne zadanie nie dostaje już czasu procesora. Co ciekawe, im lepszy 'nośnik danych' tym bardziej daje się to we znaki, ze zwykłego HDD mogę odpalić najwięcej zadań.
Na razie darowałem sobie ten projekt, bo jadąc na jednym managerze bez ciągłej ręcznej ingerencji liczy mi się tylko jedno zadanie na raz, więc punktów za dużo nie naskrobę, a pojedyńcza karta CF to za mało, żeby odpalić z niej więcej managerów z Almerami, zwłaszcza że FreeHALe dużo miejsca ostatnio zajmują (pod koniec przeliczania niektóre podchodzą pod 1GB na dysku).
Cytat: TJM w 06 Grudzień 2008, 12:14
Przez samo uruchamianie dużej liczby procesów większość czasu procesora przejmuje u mnie proces bezczynności systemowej, do tego stopnia, że z odpalonymi 4-5 almere żadne inne zadanie nie dostaje już czasu procesora. Co ciekawe, im lepszy 'nośnik danych' tym bardziej daje się to we znaki, ze zwykłego HDD mogę odpalić najwięcej zadań.
Ciekawe. Ja wciaz potwierdzam co napisalem wczesniej, ze nawet przy 45 Almerach `nie czuje` ze cos sie dzieje. Natomiast na HDD juz przy 5-ciu czulem obciazenie dysku. Tak wiec po pierwsze Almery prawie wcale nie ruszaja mi proca (nie wiecej niz FreeHAL - wiesz o co chodzi), a po drugie u mnie czym lepszy `nosnik danych` tym lepiej - zupelnie odwrotnie w stosunku do tego co Ty masz. A moze chodzi o transfer? Karty CF nie maja zbyt dobrego transferu, wiec jesli chodziloby o wewnetrzne (wewnatrz partycji) przerzucanie duzych ilosci danych, to CF moglaby wymieknac (za to i-RAM pokazalby pazury przy wewnetrznym przerzucaniu danych (w obrebie jednej kosci pamieci RAM :D)).
To raczej kwestia jakichś ustawień systemu. Szybkość transmisji nie ma tu praktycznie nic do rzeczy: uruchamiany jest w kółko ten sam exek więc po kilku uruchomieniach siedzi już na pewno w cache dysku, a pliki które ładuje są malutkie. Problem w tym, że mój system tak po prostu reaguje na uruchamianie aplikacji kilka razy na sekundę - ten sam efekt uzyskuję tworząc zapętlony plik .bat w którym uruchamiam w kółko progsa który w ogóle nic nie robi tylko od razu się kończy.
@RAD:
Jak sie tak dalej bedziemy scigac w Almere, to drugie i trzecie miejsce na swiecie mamy gwarantowane :). Na pierwsze raczej nie mam szans, bo czasu mi brakuje i szczescia (zawsze jak chce sie pobawic Almerem to nie ma WU :P).
fajnie by było,
@AiDec wczoraj mocno odskoczyłeś i postanowiłem trochę poeksperymentować, odrobiłem straty, nieco później skończyło się to totalną zwiechą kompa
(posiadam tylko 2GB ramu podczas eksperymentu liczenia wu Almere potrzebowałem 1,1GB + 200MB system + 200MB 2xBM pod Linuksem i .... podczas tworzenia statystyk WCG dodatkowe 900MB => nie udało się i 7h przestoju - po powrocie z pracy zamiast wyników zobaczyłem dwie mrugające diody na klawiaturze) :(
chwilowo muszę trochę przystopować (liczenie Almere pod kontrolą) - nie odpuszczam wyścig trwa ;)
- generalnie problemy zaczęły się przy tworzeniu statystyk wcg - skrypt potrzebował ponad 2,5GB ramu ?
po przeróbkach (wczytanie tylko jednego pliku) 900 MB i tak nie rozumiem dlaczego funkcja simplexml_load_file wczytanie/parsowanie (bo chyba tak to się nazywa) 50MB pliku potrzebuje 800MB ramu
@RAD: narzuciles ostre tempo :). Tak ostre, ze szczerze Ci powiem dlugo takiego tempa nie utrzymam :). Jak udalo Ci sie osiagnac tak swietne wyniki?
Jak chłopaki takie tempo utrzymacie do północy to może "1" bedzie nasze.
A co do projektu w pierwsze 7 jest 4 polaków wg. RAC
Cytat: malpi w 16 Grudzień 2008, 10:16
A co do projektu w pierwsze 7 jest 4 polaków wg. RAC
Tak dziala wewnetrzna rywalizacja XD
Cytat: AiDec w 16 Grudzień 2008, 09:26
@RAD: narzuciles ostre tempo :). Tak ostre, ze szczerze Ci powiem dlugo takiego tempa nie utrzymam :). Jak udalo Ci sie osiagnac tak swietne wyniki?
1. zredukowałem ilość potrzebnej pamięci RAM przy tworzeniu statystyk (przejście na obróbkę pliku txt jak mnie uczono ponad 10lat temu)
- 2,5GB -> 900MB -> 150MB RAM (obecnie)
- niestety wzrósł czas przygotowania statów 20sek -> 3min (raz na 6h da się wytrzymać - moja strata) ;)
2. eksperymenty z Boinc Managerem (jak podam to już przegrałem ten wyścig, a co mi tam) XD
- zauważyłem, że BM ściąga próbki AlmereGrid dopóki nie ściągnie jednej kompletnej i nie rozpocznie przeliczania
- uruchamiam czystego BM bez próbek (na VM lub BM drugi równolegle)
- "dławię" łącze "Maximum download rate" do 1KB/s
- w tym czasie BM inicjuje pobieranie 10 wu co 7sek (zbieram tyle wu ile potrzebuję)
- zwiększam download na maxa
- w BM client_state.xml brak/skasowana linia <non_cpu_intensive/>
- w BM cc_config.xml ustawoine tyle cpu ile mogę przeliczać Almerek -> ncpus = xxxMB_RAM/100MB
Cytat: malpi w 16 Grudzień 2008, 10:16
Jak chłopaki takie tempo utrzymacie do północy to może "1" bedzie nasze.
wow nie zauważyłem, no to warto trochę jeszcze pociągnąć
wczoraj już spasowałem przygotowuję się do wyścigu w
PrimeGridw projekcie
3x+1@home mam 22k i chcę dociągnąć do 30k_pkt (jeszcze 8k, a czasu coraz mniej)
1 miejsce w AlmereGrid będziemy mieli na bank (ale nie koniecznie dzisiaj) :attack:
Cytat- zauważyłem, że BM ściąga próbki AlmereGrid dopóki nie ściągnie jednej kompletnej i nie rozpocznie przeliczania
Tak samo jest we FreeHALu, ale tylko kiedy nie ma żadnego wcześniejszego zadania czekającego na odesłanie. Stąd używanie tricku NNW, update, wyłączenie NNW, update przy przydławionej sieci powoduje zassanie większej ilości zadań.
Niestety FreeHAL ma limit 5/core :-(
hal skrajnie drażni mój hdd - jak zrobić ramdisk?
Gdzieś wcześniej pisałem, jest programik w którym sprowadza się to do paru kliknięć i na dodatek jest on darmowy.
Nie wiem tylko czy da radę FreeHALa na RAMdisku, przez ten zakichany stderr.txt - dla niektórych zadań puchnie on do kilkuset MB, trafisz na raz dwa takie i po prostu się sypną. Na dodatek takie sypnięcie z miejsca wykrzacza też managera (poprzez brak miejsca na dysku client state). Trzebaby było wjechać na forum projektu i ponarzekać na ten stderr.txt, raczej nie jest on do niczego potrzebny poza ich testami (na serwer na pewno nie jest uploadowany), więc mogliby go usunąć w publicznej wersji aplikacji. Wtedy sam bym RAMdisk odpalił i drugie tyle zadań co mam teraz %-)
Cytat: TJM w 16 Grudzień 2008, 19:15
Gdzieś wcześniej pisałem, jest programik w którym sprowadza się to do paru kliknięć i na dodatek jest on darmowy.
naprowadź jeszcze troszeczkę :-[
Cytat: RAD-Poland w 16 Grudzień 2008, 16:46
eksperymenty z Boinc Managerem (jak podam to już przegrałem ten wyścig, a co mi tam) XD
- zauważyłem, że BM ściąga próbki AlmereGrid dopóki nie ściągnie jednej kompletnej i nie rozpocznie przeliczania
- uruchamiam czystego BM bez próbek (na VM lub BM drugi równolegle)
- "dławię" łącze "Maximum download rate" do 1KB/s
- w tym czasie BM inicjuje pobieranie 10 wu co 7sek (zbieram tyle wu ile potrzebuję)
- zwiększam download na maxa
- w BM client_state.xml brak/skasowana linia <non_cpu_intensive/>
- w BM cc_config.xml ustawoine tyle cpu ile mogę przeliczać Almerek -> ncpus = xxxMB_RAM/100MB
Robie cos podobnego, ale tylko podobnego. Jeszcze tego nie rozpracowalem dokladnie :).
Sciagam jakies 10-15 kompletnych WU (mam wtedy jeszcze ze 100 WU w kolejce sciagania). Zapinam noncpuintensive i dlawie download na 50KB. Tyle nowych WU co mi sie sciagnie, to akurat tyle starych powinno sie przeliczyc, a ja caly czas powinienem miec 10-20 WU przeliczanych na raz. W teorii :P. Na razie w praktyce jeszcze nie wyglada to tak rozowo :P.
Czy ktos wie moze jak sprawdzic czy serwery Almere maja probki? Od dwoch dni nie moge dorwac wiecej niz 1 WU na jakies 2h. A potrzebuje 50/h. Nie wiem czy dac sobie spokoj, czy probowac dalej (kosztem czasu przeliczania innych projektow). A niestety nigdzie nie moge znalezc info o statusie serwerow Almere. Czy ktos zna moze jakiegos linka?
Server status page (http://boinc.almeregrid.nl/server_status.php)
Dzieki. I sadze ze dobrze rozumiem:
Results ready to send 0
Results in progress 1,174
Ze ludziska maja w qpie 1174 WU i wlasnie je przetwarzaja, ale nie ma nowych WU do wyslania tak?
dobrze rozumiesz a aktualnie 15 wu do wysłania
Results ready to send 1 :attack:
Results in progress 1,213
nowe próbki są tworzone średnio ok 200-300 na godzinę (ale bywają przerwy)
już
Results ready to send 15
Results in progress 1,243
EDIT: trochę cierpliwości i do :attack: :attack: :attack:
EDIT: ja chwilowo wypadłem z obiegu brak VM i Windy (brak czasu) :book:
Poczekam az bedzie results ready to send co najmniej 100. Przy mniejszej ilosci nie oplaca mi sie nawet kasowac noncpuintensive (na ktorym jade 24h/dobe). Trzy dni temu skasowalem noncpu, podlapalem kilkadziesiat junitow i 700pkt w kilka godzin :) - awansowalem na 4-te miejsce na swiecie :). Nawet nie zauwazylem ze sie przeliczaly (i-RAMy :) ). Ale od tamtej pory nie moge dorwac na tyle duzo junitow, zeby sie w ogole oplacalo restartowac BM, zmieniac client_state...
Teraz bede pilnowal statusu serwera (dzieki za linka! :) ). Az sobie zrobilem 15GB wolnego miejsca na to :).
Aidec odpal z 10-20 TJM-owych menadżerów i na nich bez <non_cpu> licz almere na iramach, (wtedy praktycznie wszystkie próbki z serwera będą twoje) a jak będą próbki to komp będzie brał je w zapas
Cytat: malpi w 15 Styczeń 2009, 07:35
Aidec odpal z 10-20 TJM-owych menadżerów i na nich bez <non_cpu> licz almere na iramach, (wtedy praktycznie wszystkie próbki z serwera będą twoje) a jak będą próbki to komp będzie brał je w zapas
Potrzebuje czasu zeby sie ze wszystkim uporac. Na razie walcze z Linuksem + i-RAM`y. A TJM`owych klientow jeszcze nie zgrokowalem do konca :). Zrobie to najszybciej jak bede mogl.
Zaczynam walkę tyle, że na CompactFlash :).
Wrzucić tam C:\Temp i C:\Windows\Temp czy tylko jeden z nich?
Chyba projekt lezy i kficzy.
Cytat: AiDec w 01 Luty 2009, 21:35
Chyba projekt lezy i kficzy.
Cargo im się w porcie skończyło i nie mają co sobie ustawiać :/
Obecnie do pobrania jest 750 WU, wiec tak do końca nie leży :-[
No to jedziemy... po pierwsze miejsce na swiecie :).
WU na serwerze sa. Moj BM poprawnie requestuje, kontakt z serwerem jest poprawny, a mimo to `got 0 tasks`. Mam to od wczorajszego popoludnia, po sciagnieciu i przeliczeniu wielu WU. Zrozumialbym np. limit dzienny i dlatego wczoraj jeszcze nic nie pisalem. Ale dzisiaj rowniez mam to samo. Mozliwe ze jest limit nie na dobe, ale np. na 24h? W takiej sytuacji limit by mi sie odnowil za kilka godzin. Ale deczko to dla mnie dziwne. Czy ktos cos moze wie w tym temacie?
Dziwne to to, ale wszystko wskazuje na to ze jest limit na 48h.
Tak czy inaczej plan na dzisiaj: pierwsze miejsce na swiecie w Almere ;).
Co bedziemy robic dzisiaj w nocy? To samo co kazdej nocy - sprobujemy zawladnac swiatem! :arrr:
Czy Almere korzysta z CPU?
Bo wydawało mi się, że nie (a przynajmniej śladowo), a nie chce mi uruchomić przeliczania.
Coś trzeba ustawić (np. w cc_config)?
1. Korzysta tylko sladowo.
2. Nalezy recznie dopisac non cpu intensive (wez np, z FreeHAL`a).
3. A co, chcesz sobie HDD zajezdzic? ;) Czy masz RAMdysk?
Swoją drogą, testował ktoś Almere na Win98 ? Tam keszowanie plików na dysku było jakieś takie sprawniejsze niż w późniejszych systemach, może nie łomotałoby tak dyskiem i nawet na zwykłym HDD dałoby się odpalić ;D Gorzej z tym, że Win98 raczej nie da się na żadnym w miarę nowym kompie zainstalować normalnie (co najwyżej posiłkując się drugim, starszym kompem w dwóch pierwszych fazach instalacji), a potem praca systemu także pozostawia wiele do życzenia.
A może by tak wirtualkę w ramdisku umieścić ??
Ja almere od ponad miesiąca licze (oczywiście komp w pracy chodzący 24h/dobe) i żadnych dziwnych dźwięków nie wydaje,
a co do pena to bardzo szybko zajeżdża - około 48h działał, a później same błędy sie sypały
Cytat: AiDec w 13 Luty 2009, 14:34
2. Nalezy recznie dopisac non cpu intensive (wez np, z FreeHAL`a).
A jak się to obsługuje - bo mi manager coś nie rozpoznaje tego
1. Zresetuj Almere.
2. Jak sie juz od nowa polaczy, to wyjdz z BM (zakoncz BM) i upewnij sie ze wszystkie BOINCowe procesy sa zakonczone.
3. Otworz client_state.xml.
4. Znajdz Almere (CTRL+F Almere).
5. Dodaj linijke:
<non_cpu_intensive/>
Ma to wygladac tak:
<send_time_stats_log>0</send_time_stats_log>
<send_job_log>0</send_job_log>
<non_cpu_intensive/>
<attached_via_acct_mgr/>
<ams_resource_share>100.000000</ams_resource_share>
lub tak:
<send_time_stats_log>0</send_time_stats_log>
<send_job_log>0</send_job_log>
<attached_via_acct_mgr/>
<non_cpu_intensive/>
<ams_resource_share>100.000000</ams_resource_share>
Jakby mimo wszystko cos bylo dla Ciebie niejasne, to podepnij sie pod projekt FreeHAL i zobacz jak to wyglada w clientstate (bo to identyczna sytuacja z noncpu, tyle ze FreeHAL automatycznie zapina noncpu, a w Almere trzeba dopisac).
Ale uprzedzam - tego sie nie liczy na normalnym HDD. Chyba ze masz juz odlozona kase na nowy HDD ;). Jak chcesz liczyc cos na noncpu a nie masz BOINCa na RAMdysku (lub podobnym), to bierz FreeHAL`a. Tym bardziej ze we FreeHALu przyda sie kazda pomoc dla teamu, a w Almere to moge za caly team robic ;).
HDD od tego nie padnie tak za łatwo, gdyby tak było to dyski w serwerach umierałyby w ciągu paru dni, a przecież tak nie jest. U mnie w serwerze Enigmy dyski młócą głowicami 24/7/365 i póki co nic im nie jest. Ale i tak strata czasu liczyć raczej almere na zwykłym dysku, po prostu za długo to trwa i za mało zadań na raz da się odpalić, żeby miało to sens.
Dzięki Aidec.
W swojej ciemnocie wciskałem <non_cpu_intensive/> do pliku cc_config.xml zamiast client_state.xml ::)
i się dziwiłem że mi nie działa.
FreeHALa już cisnę ile mogę, a że często zerkam na status próbek to staram się jak najczęściej resetować projekt, żeby liczył po 3 na raz.
A Almere chciałem tylko dociągnąć do 1000pkt. Czy bez sztuczek licząc normalnie po jednej próbce na raz też mogę zajechać dysk? (miałoby chodzić na firmowym kompie... sami rozumiecie)
Raczej nie, ja licze po 5 naraz, juz od ponad miesiąca i dysk nie narzeka 8)
Cytat: AiDec w 13 Luty 2009, 15:58
1. Zresetuj Almere.
2. Jak sie juz od nowa polaczy, to wyjdz z BM (zakoncz BM) i upewnij sie ze wszystkie BOINCowe procesy sa zakonczone.
3. Otworz client_state.xml.
4. Znajdz Almere (CTRL+F Almere).
5. Dodaj linijke:
<non_cpu_intensive/>
Ma to wygladac tak:
<send_time_stats_log>0</send_time_stats_log>
<send_job_log>0</send_job_log>
<non_cpu_intensive/>
<attached_via_acct_mgr/>
<ams_resource_share>100.000000</ams_resource_share>
lub tak:
<send_time_stats_log>0</send_time_stats_log>
<send_job_log>0</send_job_log>
<attached_via_acct_mgr/>
<non_cpu_intensive/>
<ams_resource_share>100.000000</ams_resource_share>
Pytanie:
1. Przy ponownym połączeniu, po resecie, ma pobrać nowe próbki, czy dopiero po zmianie w pliku?
2. Almere pojawia mi się w dwóch miejscach w pliku xml, w jednym jest
<ams_resource_share>100.000000</ams_resource_share> a w drugim nie
EDIT:
Zagadka 2 Almere się już wyjaśniła, jestem podpięty dwa razy. Tylko który adres jest właściwy...
Ten podpięty przez BAM czy ten ręcznie?
Ad 1, 2 i reszta :):
Reset projektu po to, zeby Ci wyczyscic projekt (ewentualne niepoprawne zmiany w clien_state). W Twojej sytuacji najlepiej odepnij Almere w kazdy mozliwy sposob i zapnij od nowa (przez BAM lub nie - jak wolisz). Zacznij od nowa z `czystym wpisem`, to bedzie Ci latwiej. Wtedy wylacz BOINCa, wprowadz zmiany i bedzie liczyl na non-cpu. Juz nic wiecej nie musisz robic.
Już jakoś poszło. Bez odłączania. Zobaczymy jak będzie chodził.
czy jest sens podpinania do almere takiego kompa?
amd 450mhz ze 128 ramu i dwa dyski (jeden to 1,7 a drugi to 1,0 GB) Oba dyski mogą iść na zarżnięciea komp i tak jest na wylocie (oddam w dobre ręce albo za jakiś czas wyleci na śmietnik)
Spróbować możesz... ja odpalałem Almera i FreeHAL'a na Celeronie 525MHz z 392MB RAM... i szło
Mam pytanie do aktywnie liczących w tym projekcie: od dawna brakuje zadań i serwer niby 'shutdown for maintenance' ? Wróciły mi z serwisu dwa dyski, kanalie wymienili na takie z zielonymi obwódkami i napisem 'Certified Repaired HDD' więc chcę im dobrze dać w palnik w ramach testu sprawności, jak mają się posypać to niech to zrobią szybko %)
Results ready to send 213
Results in progress 797
Workunits waiting for validation 6
czyli chyba nie maintenance :D
data-driven web pages aqua Running
upload/download server aqua Running
scheduler aqua Running
feeder aqua Running
transitioner aqua Running
file_deleter aqua Disabled
db_purge aqua Running
aqua_validator aqua Running
aqua_assimilator aqua Running
aqua_cuda_validator aqua Running
aqua_cuda_assimilator aqua Running
Manager pokazywał przez dłuższy czas maintenance, ale teraz widzę, że się już odblokowało, pozostaje czekać na zassanie zadań %)
czasami są przestoje z próbkami, ale da się trochę nałapać
mnie pobrał jedną przed jakąś godziną (więcej na raz nie mielę, bo to pracowy komp i nie chciałbym, żeby coś padło ;) )
Nie mieli już dyskiem tak jak kiedyś, ale nadal pojedyńcze zadanie pare milionów operacji I/O wykonuje w ciągu ~5 minut przeliczania.
właśnie pobiera mi następny WU
U mnie w końcu poszło hurtem i zassało kilkanaście na raz, muszę zaraz pokombinować jak to się robiło z tym non_cpu_intensive żeby trochę rozpędzić obliczenia (i głowice w dyskach). Zobaczymy co warte są dyski po naprawie :D
Dziwna sprawa, parę zadań mi przeliczyło i zaczęły się schody: przy każdym WU informacje, że przekroczył maksymalny czas elapsed po czym zadanie zostaje zatrzymane i odesłane z błędem, punktów nima. Ktoś z was też ma coś takiego, czy to kolejny z wielu bugów managerów 6.6.x ?
U mnie normalnie działa, ale jadę na 6.5.0
A co do bugów 6.6.x to zaraz zgłoszę kolejny w odpowiednim wątku... ::)
- Almere wciaz licze, choc na cwierc gwizdka bo mam inne zajecia, ale licze caly czas.
- Probki sa dostepne prawie zawsze, serwery dzialaja prawie zawsze.
- @TJM: nie mialem takich klopotow - wszystkie probki przeliczaja sie u mnie bezproblemowo.
Cytat: TJM w 25 Czerwiec 2009, 00:23
Dziwna sprawa, parę zadań mi przeliczyło i zaczęły się schody: przy każdym WU informacje, że przekroczył maksymalny czas elapsed po czym zadanie zostaje zatrzymane i odesłane z błędem, punktów nima. Ktoś z was też ma coś takiego, czy to kolejny z wielu bugów managerów 6.6.x ?
Miałem ten sam problem, dałem sobie po prostu spokój z tym projektem.
Oczywiście manager 6.6.31 po niecałych 24h liczenia zdziczał mi kompletnie i przestał pobierać zadania (klasyk dla tej serii - work request ale pusty). Przeinstalowałem na 6.6.36 żeby sprawdzić czy coś się zmieni, ale akurat serwer chyba ma jakieś problemy bo nic nie chce się zassać.
Jest rozwiązanie na problem auto anulowania zadań. Po ich pobraniu trzeba zamknąc managera, otworzyć plik client_state i we wszystkich rsc_fpops_bound dla tych zadań dopisać co najmniej jedno zero, a lepiej jeszcze dwa. Domyślnie timelimit jest ustawiony na około 7 minut (przynajmniej na moim cpu, według benchmarka). W starych managerach było to 7 minut czasu CPU, w nowych jest to 7 minut wall clock time, przez co każde zadanie trwające dłużej zostanie anulowane. Dopisanie jednego zera zamienia to w 70 minut, dlatego lepiej od razu dopisać dwa - u mnie niektóre WU sięgają 40 minut przeliczania, zwłaszcza jak odpala się po kilka na raz.
Cytat: TJM w 25 Czerwiec 2009, 18:11
Jest rozwiązanie na problem auto anulowania zadań. Po ich pobraniu trzeba zamknąc managera, otworzyć plik client_state i we wszystkich rsc_fpops_bound dla tych zadań dopisać co najmniej jedno zero, a lepiej jeszcze dwa. Domyślnie timelimit jest ustawiony na około 7 minut (przynajmniej na moim cpu, według benchmarka). W starych managerach było to 7 minut czasu CPU, w nowych jest to 7 minut wall clock time, przez co każde zadanie trwające dłużej zostanie anulowane. Dopisanie jednego zera zamienia to w 70 minut, dlatego lepiej od razu dopisać dwa - u mnie niektóre WU sięgają 40 minut przeliczania, zwłaszcza jak odpala się po kilka na raz.
A, wiesz gdzie to może jest zakopane w kliencie?, ja wolałbym sobie przekompilować core niż za każdym razem bawić się w zmianę w xml-ach
Cytat: TJM w 25 Czerwiec 2009, 11:19
Oczywiście manager 6.6.31 (...)
Przeinstalowałem na 6.6.36 (...)
Prosisz sie o klopoty XP. Pobaw sie jeszcze 6.6.20, 6.6.28... Jak masz probek nabrane na nastepny tydzen... ;).
zawsze można oskryptować, ale...
zmiana w/w parametru to już "cheating", a w połączeniu z kręconym/optymalizowanym benchmarkiem to już mocny przekręt, (mamy specjalny wątek na takie tematy)
już raz o tym pisałem tylko raz w całej historii boinc spotkałem się z oficjalną prośbą twórców jednego projektu o zmianę tego parametru, rozesłali nieco dłuższe próbki "climate"
parametr ten jest jednym z zabezpieczeń przed "przekrętami" na wielu forach jest to opisane oraz zabezpieczeniem liczących przed utratą dużej ilości punktów w przypadku zapętlonych/uszkodzonych próbek
EDIT: literówki ;)
To może ktoś znający niemiecki napisałby do twórców projektu żeby wydłużyli czas w rsc_fpops_bound tak żeby na wolniejszych prockach (Athlon64 3200+) można było ten projekt spokojnie policzyć.
Nie sądzę, żeby rsc_fpops_bound w jakikolwiek sposób mogło wiązać się z cheatowaniem. Zmiana tego parametru nie zmienia nic oprócz maksymalnego czasu przez jaki zadanie może być uruchomione przed auto anulowaniem.
Na dodatek w tym wypadku jedynie zmniejszanie benchmarku ma sens, zwiększanie jeszcze potęguje problem, ponieważ wyższy benchmark oznacza krótszy maksymalny czas przeliczania i zadanie po prostu szybciej się wyłoży.
ostatnio jak liczyłem to u mnie dla AMDX2 3800+ 2,0@2,2 Win32 limit cpu był ok 8min (czyli blisko tego co TJM) pozwalało to na przeliczanie jednoczesne 4-5 wu na rdzeń (4 przy normalnej pracy przy komputerze i 5 w nocy), dla Celerona 1,2G (limit był ok 15 min i wytrzymywał 7wu jednocześnie), zwiększenie liczby jednocześnie przeliczanych wu powodował błędy max_cpu_time.
Zakończyłem liczenie tego projektu (03.2009) gdy przeglądając wyniki innych użytkowników zorientowałem się, ze niektórzy by osiągnąć więcej punktów stosowali korektę final_cpu_time przed odesłaniem próbki, a przeliczając benchmark i <rsc_fpops_bound>, próbki wielokrotnie przekraczały max_cpu_time
@sesef nie wiem dlaczego w Twoim przypadku przeliczanie wu nie mieści się w rsc_fpops_bound,
@TJM jeśli chodzi o punkty to bez szczypania się zwiększ rsc_fpops_bound x1M i benchmark x1M, a za przeliczenie jednej wu ok 3-5 min otrzymasz ok 1,2Mpkt, jesli natomiast chodzi o test HDD (ile wytrzyma przed padem) to jak najbardziej x10 to pozwoli na przeliczanie 10 razy tyle próbek (choć niekoniecznie bo czasy dostępu do HDD są nie linowe przy wzroście operacji I/O ...) i przy okazji 10 razy punktów
EDIT: @TJM nawet nie zmieniając benchmarka, a zwiększając tylko rsc_fpops_bound i ilość próbek, zwiększysz czas przeliczania wu i ilość żądanych punktów za jej przeliczenie, a tym samym ilość otrzymanych punktów, chyba że zmienili system punktowania to sorry za zamieszanie
Nadal nie rozumiem w jaki sposób edycja fpops_bound po stronie klienta może zmieniać punktację. Przecież to się ustawia w template workunita po stronie serwera jedynie w tym celu, żeby poinformować klienta jak długo maksymalnie może potwać liczenie WU i po upłynięciu tego czasu następuje autokill zadania.
Niektóre projekty mają tam wpisane wartości całkowicie z kosmosu (np. ja takich użyłem) i nic się nie dzieje. Jeśli aplikacja działa sprawnie i nie może wpaść w jakiś infinite loop, to można tam wpisać cokolwiek, ważne żeby było wyższe od rzeczywistego czasu przeliczania.
Co innego fpops_est, tutaj już podejrzewam że mógłby być jakiś wpływ (na podstawie tej wartości klient szacuje m.in. czas przeliczania czegoś), ale nadal nie rozumiem po co serwer miałby brać tą wartość od klienta, skoro to samo ma zapisane w bazie danych ? To samo zresztą dotyczy rsc_fpops_bound.
Jedyna zmiana która pozwalałaby na cheatowanie, to ustawienie najpierw benchmarka w kosmos a później fpops_bound również z tym samym mnożnikiem, po to tylko żeby BOINC przedwcześnie nie wyłączył zadania. Ale cheatowanie w ten sposób to nadal cheatowanie samym benchmarkiem.
sorki za cytowanie samego siebie
Cytat...
EDIT: @TJM nawet nie zmieniając benchmarka, a zwiększając tylko rsc_fpops_bound i ilość próbek, zwiększysz czas przeliczania wu i ilość żądanych punktów za jej przeliczenie, a tym samym ilość otrzymanych punktów, chyba że zmienili system punktowania to sorry za zamieszanie
sprawdź, a się przekonasz, a na dodatek jest jeszcze wiele innych projektów podatnych na ten "trik" jeśli nie nazywać tego "cheatem" (przy czym należy spełnić jeszcze inne warunki, ale o nich nie napiszę z przyczyn oczywistych)
To co napisal RAD to prawda i jest to wciaz aktualne. Wszystko. Wlacznie z mozliwosciami cheatowania. I sposobu punktacji wciaz nie zmienili.
Analizowałem sytuację i nadal nie widzę jakiegokolwiek związku między fpopsami a kredytami w tym projekcie. Niezależnie od tego ile czasu faktycznie mieli się zadanie (a wiadomo, że na zwykłym HDD odpalenie kilku na raz spowalnia znacznie przetwarzanie i między jednym a 5-ma różnica w czasie jest 3-krotna) dostaję około 1,5 punkta. To dlatego, że do serwera raportowany jest czas CPU (który dla almere i tak jest nieprawdziwy, ponieważ używany wrapper bierze go niejako z kosmosu, w każdym razie nie ma on nic wspólnego z prawdziwym).
Żeby coś tu wycisnąć, trzeba by przed zaraportowaniem wyedytować czas CPU dla każdego zadania.
Nawiasem mówiąc, jeśli da się cheatować zmieniając kilka parametrów, warto by to zgłosić w tickecie; gdyby tak do kodu serwera dodać sprawdzanie wartości zwracanych z pliku .xml z tymi zapisanymi w bazie (do klienta wysyłana jest dokładna kopia), oszukiwanie stałoby się znacznie trudniejsze, bo wymagałoby co najmniej dwukrotnej edycji plików.
EDIT: nawiasem mówiąc, coś nie tak chyba z serwerem, wczoraj były błędy bazy danych a teraz na stronie mam niby kilkadziesiąt przydzielonych do klienta zadań podczas gdy zostały one już dawno odesłane, chyba jeszcze przed padem.
Ano serw padl, chyba sie zarazil od Einsteina XP.
W nocy rozsypał się jeden z 'Certified Repaired HDD' Seagate po starciu z Almere :D Idzie znów na gwarancję, jak mi znowu oddadzą naprawiany to będzie kolejny test wytrzymałości. Drugi na razie się trzyma, może lepiej go naprawili.
Niestety serwer znów nie działa i nie mogę kontynuować stress testów.
No i serwer ruszył, ale dalej bez edytowania plików na zwykłym hdd ciężko cokolwiek przeliczyć mając szybki proc na pokładzie. Pisałem w tej sprawie do kogoś kto zdaje się ma jakieś flagi developera, ale nie dostałem żadnej odpowiedzi.
Wczoraj już na drugim kompie Almerka zakończyła się błędami. Po przeczytaniu tego wątku wiem już co i jak, ale nie zamierzam bawić się tym gównem - kompy używam też do pracy.
Mam jedną prośbę - dla takich początkujących jak ja umieśćcie tu: http://www.boincatpoland.org/wiki/AlmereGrid ostrzeżenie o tym projekcie. Szkoda, aby inni się wkurzali i tracili entuzjazm dla idei BOINC, prawda?
1. Wszystko zostaloby zrobione, jesli tylko czas by byl.
2. A jak ja ostrzegam przed Almere, FreeHAL`em to mi pisza ze wcale takie zle nie sa XP.
Cytat: AiDec w 28 Lipiec 2009, 12:182. A jak ja ostrzegam przed Almere, FreeHAL`em to mi pisza ze wcale takie zle nie sa XP.
Jak dla mnie, to jest zasadnicza różnica między FreeHALEM a Almere - FH liczy i daje punkty, a Almere nie. :)
A komus innemu bedzie na odwrot dzialalo XP. Almere bedzie chodzic, a FreeHAL bedzie wieszal kompa.
Z Almere może być teraz ciężko na każdym w miarę szybkim procu z wysokim benchmarkiem - dla proców Intela barierę oceniam tak na 2,8-3.0GHz. Po prostu im wyższy benchmark, tym krótszy będzie czas działania aplikacji zanim BOINC ją ubije, a czas przeliczania praktycznie w ogóle nie zależy od procesora.
Komunikat dla wlascicieli i-RAM`ow, RAM-dyskow i sluzbowych HDD ;):
W Almere ostatnio cos ruszylo. `Cos`, jest nawet za malym slowem. Ruszylo jak huragan. Server generuje do kilku tysiecy probek dziennie (stabilnie). Moj Kosmos chodzi z Almere na 90% mozliwosci przez 100% czasu (robie po 3000 pkt. dziennie na Almere!) i jeszcze pare setek WU bardzo czesto wisi na serwie. Wszystkie znaki na niebie i ziemi wskazuja, ze ta sytuacja nie zmieni sie w najblizszym czasie.
jutro dogadam się z ramdyskiem %)
Cytat: TJM w 25 Czerwiec 2009, 18:11
Jest rozwiązanie na problem auto anulowania zadań. Po ich pobraniu trzeba zamknąc managera, otworzyć plik client_state i we wszystkich rsc_fpops_bound dla tych zadań dopisać co najmniej jedno zero, a lepiej jeszcze dwa. Domyślnie timelimit jest ustawiony na około 7 minut (przynajmniej na moim cpu, według benchmarka). W starych managerach było to 7 minut czasu CPU, w nowych jest to 7 minut wall clock time, przez co każde zadanie trwające dłużej zostanie anulowane. Dopisanie jednego zera zamienia to w 70 minut, dlatego lepiej od razu dopisać dwa - u mnie niektóre WU sięgają 40 minut przeliczania, zwłaszcza jak odpala się po kilka na raz.
Od dawna miałem ten problem i nawet do głowy mi nie przyszło, żeby tu zerknąć XD
Dzięki za rozwiązanie - pomogło. Mam pytanie odnośnie tego czy jest jakiś wygodniejszy sposób. U mnie pobiera tylko po kilka wu (góra 6), więc każdorazowe kilowanie BOINC'a i edycja w/w pliku jest męcząca. Nie da się tego rozwiązać jakoś bardziej systemowo?
BTW
Pigu jak to robisz, że zdobywasz tyle punktów co dzień? Ja od dawna próbuje dobić tylko do 5k i idzie mi jak po grudzie.
Jako ciekawostkę na potwierdzenie tezy
TJM'a podaje, że do momentu odkrycia w/w rozwiązania punktował mi w tym projekcie tylko najsłabszy host (stary athlon xp 2000).
8GB ramu, wielki ramdysk, w cholerę i trochę zadań na raz %)
@Pigu
A zjada Ci procesor przy obliczaniu kilkunastu WU na raz? U mnie mimo ustawionego "non cpu intensive" zabiera czas procesora, choć na liście procesów, "proces bezczynności" ma około 90%.
przy tej ilości coś tam musi jeść, ale to nie przeszkadza mi liczyć poza tym bezstratnie milki, kilkudziesięciu halów i może suma sumarum trochę wolnie wcg
Almere zżera moc procesora właśnie 'procesem bezczynności'.
A to dlatego, że wykonując dużo operacji I/O zajmuje przerwania. Stąd jedyne dobre rozwiązania to RAMdisk albo iRAM.
Robione na ramdisku, czyli znika komunikacja przez kontrolery dysków a mimo tego wciąga procka. :(
To coś z samym systemem.
Generalnie miałem to samo i z tego powodu odpuściłem sobie ten projekt.
Na Win2k ze słabym procem i resztą sprzętu nie brało mi proca w ogóle, a na XP już gorzej - proces bezczynności łakomie podjadał.
u mnie vista 64
Hmm, na xp32 i na xp64 podjada. Sprawdzę inny system.
turkuć podjadek
Wracając do mojego pytania - macie jakieś pomysły?
Pomysłów nie, ale za to klienta który jest rozwiązaniem tego problemu może by się znalazło.
odpal na ramdysku halowca - ok 100MB na wu
Cytat: Pigu w 23 Marzec 2010, 23:34
odpal na ramdysku halowca - ok 100MB na wu
U mnie xeon nawet z Iramem nie wyrabia czasami dlatego dalem sobie spokoj z tym projektem.
Cytat: TJM w 23 Marzec 2010, 23:24
Pomysłów nie, ale za to klienta który jest rozwiązaniem tego problemu może by się znalazło.
Chętnie przyjmę go pod strzechę - jak tylko go znajdziesz.
Trochę kulawy ten projekt więc niestety też spasowałem. ;)
Pytanie do innych liczących, czy przetwarzanie pojedynczych próbek może zajechać dysk?
Pytanie czy ten projekt jakoś normalnie punktuje ? Bo paczka liczy się u mnie pół godziny, proca zżera jak każda, a punktów daje naprawde mało. NAwet sie zastanawiam czy jest sens do 100 punktów dojeżdzać.
Cytat: KrzychuP w 17 Maj 2010, 22:42
Pytanie do innych liczących, czy przetwarzanie pojedynczych próbek może zajechać dysk?
Jezeli bedziesz liczyl po jednej na raz, chocby 24/7, to moim zdaniem `zajechanie` jest wykluczone. Niemniej w jakims tam blizej nieokreslonym (choc IMHO bardzo nieznacznym) stopniu zmniejszy Ci zywotnosc HDD. Zalecalbym raczej odpalenie jakiegos Virtualnego dysku w RAMie - polecam RamDisk Plus, istnieje praktycznie na kazda platforme, w tym W7x64 ( http://www.superspeed.com/desktop/ramdisk.php ).
Cytat: PMG w 18 Maj 2010, 00:48
Pytanie czy ten projekt jakoś normalnie punktuje ? Bo paczka liczy się u mnie pół godziny, proca zżera jak każda, a punktów daje naprawde mało. NAwet sie zastanawiam czy jest sens do 100 punktów dojeżdzać.
Ten projekt punktuje calkowicie nienormalnie :). Liczenie w standardowy sposob daje bardzo malo punktow.
RamDisk + HALowiec + Almere - działa :)
Zalecam minimum 768MB ramdiska na mniejszym 512 pisało że za mało hdd space mimo zmiany preferencji boinca.
A ten "halowiec" to co to za twór, jakaś zmodyfikowana wersja menagera boinca? Na windzie to to cudo się odpali?
HAL`owiec, to nic innego jak BOINC Manager (poczatkowo w bardzo starej wersji 5.10.45), ktory zostal przez jednego z naszych liczydlowych przystosowany, do dzialania jako wersja `absolutnie portable`. Wiecej informacji znajdziesz w dzialach:
http://www.boincatpoland.org/smf/aktywne/freehalhome/
http://www.boincatpoland.org/smf/boinc-manager/klienty-halowe/
...jak rowniez w tym dziale, jesli poczytasz wszystko od poczatku.
HAL`owce powstaly poczatkowo jako wersja na 32 bity, pozniej dzieki pomocy lepszych ode mnie powstaly klienty x64 (co dla Almere akurat nie ma zadnego znaczenia). HAL`owce dzialaja na wszystkich odmianach Windows (i tylko Windows). Nazwa wziela sie stad, ze poczatkowo `klienty HALowe` powstaly z mysla o liczeniu wiekszej ilosci jednostek w projekcie FreeHAL. Jakis czas temu, TJM sprokurowal HALowce na podbudowie nowszej wersji BM, 6.5.0, ktora moim zdaniem byla jedna z najbardziej udanych wersji BOINC Mangera. Wersja 6.5.0 HALowca zawiera szereg dodatkowych mozliwosci opisanych w pliku readme - w celu otrzymania HALowca w wersji 6.5.0 nalezy sie zglosic do TJM.
Obecnie HALowce sluza glownie do liczenia Almere, lapania dodatkowych probek w niektorych projektach, badz do `rozdzielenia` projektow miedzy rozne klienty - dzieki HALowcom, jest mozliwe posiadnie kilku klientow na raz w systemie, przy czym nie ma znaczenia gdzie te HALowce beda sie znajdowaly - mozna miec kilkanascie HALowcow, a kazdego na innym HDD (stosujac klienta oryginalnego, mozesz zainstalowac tylko jednego klienta w systemie). HALowca mozna tez wrzucic do wirtualnego HDD stworzonego w RAMie, co daje ogromne mozliwosci liczenia Almere, bez zadnego negatywnego wplywu na dzialanie systemu. HALowce mozna rowniez wykorzystywac do obslugi `beznetowcow` (kompow nie podlaczonych do netu) i za ich pomoca przenosic probki miedzy kompami.
Uprzedzam:
- HALowce sa dla wielu liczydlowych bardzo trudne w obsludze.
- Zabronione jest korzystanie z HALowcow w projekcie FreeHAL.
Dzięki za bardzo obszerne informacje. Zagłębię temat dla samej ciekawości. :)
Cytat: AiDec w 18 Maj 2010, 23:52Zabronione jest korzystanie z HALowcow w projekcie FreeHAL
Pomijając bezsens merytoryczny czegoś takiego i ogólnie znane "uwarunkowania historyczne", a może nawet narodowościowe, to mam pytanie i nie jest to złośliwość...
Gdzie taki zakaz jest sformułowany w projekcie?
Patrzę na "zasady i reguły" i nie znajduję takiego zastrzeżenia.
http://freehal.net/freehal_at_home/info.php
Analizując wyniki z ostatnich dni zaczynam mieć podejrzenie, że największym "cheaterem" w projekcie jest... jego autor. XD
Z drugiej strony - i to pytanie do TJM - czy autor projektu (wg zasad BOINC) może przyznać komuś ekstra ileś punktów (z pół melona), za jakieś "szczególne usługi"?
Może od razu sprzedawać punkty i przestaną się z tym kryć XD
Też mam wrażenie, że koleś zrobił sobie z tego źródło utrzymania. Jak na razie zero jakichkolwiek wyników naukowych, nic nie robiący program. Żyć i zgarniać kasę z PayPal'a... %)
aż tak dużo to kolo nie dostaje....
Pojawiły się nowego rodzaju próbki w Almere.
Włączają się jako noncpu, a zżerają całe jajo :wth:
A punktacja?
w d...e mam punktację jak mi się proc przełącza między pięcioma wątkami na 4 rdzeniach, bo spada wydajność liczenia i zaczyna czasem mulić
pytanie jest czy ktoś to liczy (szczególnie do AiDeca) i czy nie da się jakoś ustawić, żeby nie liczyło go jako noncpu tylko jak zwykłą próbkę
Na razie nie licze - niestety jestem zajety gdzie indziej :(.
Cytat: KrzychuP w 12 Październik 2010, 11:48
w d...e mam punktację jak mi się proc przełącza między pięcioma wątkami na 4 rdzeniach, bo spada wydajność liczenia i zaczyna czasem mulić
pytanie jest czy ktoś to liczy (szczególnie do AiDeca) i czy nie da się jakoś ustawić, żeby nie liczyło go jako noncpu tylko jak zwykłą próbkę
Ustaw w BOINCu ograniczenie liczby rdzeni do 3, to da ten sam efekt.
Cytat: TJM w 13 Październik 2010, 00:30
Ustaw w BOINCu ograniczenie liczby rdzeni do 3, to da ten sam efekt.
o tym sobie pomyślałem, ale musi poczekać aż dokończę inne cele :)
jest jakas wielka roznica miedzy app na Win i Linux ? (w szybkosci liczenia)
Nie wiem - nie probowalem.
Ale tak zupelnie przy okazji napisze, ze jest ogromna roznica miedzy klasycznym HDD (3 WU na raz mula HDD) a liczeniem w RAM (wirtualny HDD - 20 WU na raz przy dobrym procu).
w tym projekcie czy ogolnie ? :)
Ten projek już tak nie tnie dysku jak kiedyś. Liczyłem ostatnio do checkpointa przez kilka dobrych dni i nie było tak tragicznie.
Cytat: Tomasz R. Gwiazda w 18 Styczeń 2011, 08:57
w tym projekcie czy ogolnie ? :)
W tym konkretnym projekcie.