OProject

[Troll81]

OProject- podprojekt Wierd. wywala wszystkie próbki z errorem. w logach żadnych błędów. WTF?

[KrzychuP]

a ja mam pytanie jak to jest z tym ALX, jest "nci" czy nie?
do niedawna tak działał, a teraz jak się włącza to niby używa 1 rdzenia, a jak podglądam obciążenie to rdzeń stoi pusty

reset projektu pomoże?

[stiven]

Nie pomoże. On tak ma.

[Teech]

ALX nie obciąża procka (NCI)

[Szopler]

Ale blokuje jeden rdzeń... więc dupa a nie NCI.

[sknd]

mi sie jakoś udało parę razy metodą wstrzymywania/wznawiania zadań odpalić go tak, że nie zjadał rdzenia, ale na pewno potrzebował wolnego by pobrać jednostkę. Niestety nie pamietam jak dokładnie to robiłem i nie przypomnę sobie, bo obecnie upolować ALX-a to jak szóstkę w totka trafić...

[stiven]

A ktoś wie czemu właściwie on tak ma? Irytujące to jest.

[Teech]

Zaglądnij do menadżera zadań/procesy 1.4 windoas intel 86 (NCI)
alx_1.4_windows_x86_64__nci

[KrzychuP]

mi sie jakoś udało parę razy metodą wstrzymywania/wznawiania zadań odpalić go tak, że nie zjadał rdzenia, ale na pewno potrzebował wolnego by pobrać jednostkę

u mnie też to działało, do czasu

obecnie upolować ALX-a to jak szóstkę w totka trafić...

dostaję gdzieś od tygodnia przynajmniej po kilka dziennie, jak tylko rdzeń się zwolni

[stiven]

U mnie ciągle:

2013-01-01 15:22:43 | OProject@Home | No tasks are available for Shor's Algorithm
2013-01-01 15:22:43 | OProject@Home | No tasks are available for Shor's Algorithm DP
2013-01-01 15:22:43 | OProject@Home | No tasks are available for ALX
2013-01-01 15:22:43 | OProject@Home | No tasks are available for Weird Engine
2013-01-01 15:22:43 | OProject@Home | Project has no tasks available

Myślicie, że to przez trwający wyścig?

Przy okazji Weird Engine potrafi zjadać ponad 1 GB ramu na 1 WU i powodować niestabilność systemu.

[mimeq]

U mnie na Win7 x64 max 51xMB na WU (laptop i3 z 4GB RAmu) - na razie liczy bez problemowo.
Na c2d z 2GB RAMu (Win7 x64) - nie chce pobrac weirdow twierdzac ze brak WU weird...
c2d win XP 32 bit z 2GB RAMu - jak wyzej - brak weird engine

Reszte sprawdze jak skoncza mi sie WU Asteroids.

[Rysiu]

U mnie ciągle:

2013-01-01 15:22:43 | OProject@Home | No tasks are available for Shor's Algorithm
2013-01-01 15:22:43 | OProject@Home | No tasks are available for Shor's Algorithm DP
2013-01-01 15:22:43 | OProject@Home | No tasks are available for ALX
2013-01-01 15:22:43 | OProject@Home | No tasks are available for Weird Engine
2013-01-01 15:22:43 | OProject@Home | Project has no tasks available

Myślicie, że to przez trwający wyścig?

Przy okazji Weird Engine potrafi zjadać ponad 1 GB ramu na 1 WU i powodować niestabilność systemu.

Być może coś się zapycha ale nie powinno. Na jakim systemie 1 GB RAM'u i problemy ze stabilnością?

[stiven]

Na win7 64 bit. Obecnie leży.

Liczę też na win xp 32 bit.
Teraz pobiera tylko ALX mimo, że w ustawieniach projektu dałem:

Shor's Algorithm: yes
Shor's Algorithm DP: yes
GSCE-SV: no
ALX: no
Weird Engine: yes

Aktualizowanie, resetowanie projektu, przypinanie i odpinanie nie pomaga. Czy nie jest tak, że projekt błędnie odczytuje lokalizację komputerów i preferencje dla nich ustawione.

[Dario666]

Ja ma na Win7 x64 i WinXP x32 i działa, z tym, że:
1. Wired zżerają jakieś 530 MB, ale liczą się w niecałe 2 minuty
2. W GSCE nie widać postępu - cały czas 0,00%, aż wskoczy 100% i koniec
3. ALX zżerają cały rdzeń i nic nie robią dlatego liczę je tylko na HT.

[sknd]

ale ALX liczą ci się 16 sekund, czy jakoś długaśnie?

[andy101fah]

Potwierdzam, na moim I7 2600k pod kubuntu 12.10 64bit ALX liczą się 16 sekund.

[Dario666]

Zauważyłem taki problem z tym projektem, że CPU Time na ALX'ie nie rośnie mimo ostrego walczenia z tym projektem :)

[stiven]

ALX jest a przynajmniej powinien być (czasem rezerwuje sobie cały rdzeń) NCI więc CPU nie zjada. Wg ostatniego info z forum projektu robi nic chyba że o czymś nie wiem. Dodatkowo jest o tyle upierdliwy, że próbki się zasysają nawet gdy wyraźnie zaznaczymy w ustawieniach by tak się nie działo.

[Dario666]

Ostatnio przetworzyłem z 40000 WU ALX'az, a przyrosło mi może z 30 godzin. CHORE!!!  :wth:

[mimeq]

Bylo "walkowane" juz kilkukrotnie. Wszystko zalezy od danych umieszczonych na stronie glownej, pokazuja one status danych:

Kod [Zaznacz] Rozwiń

Tasks:
| Unsend: 177 122
| In progress: 5 656
| Over: 668 614

W tym przypadku chodzi o ostania pozycje Over - liczba zadan ktore oczekuja na dodanie do bazy statystyk. Jesli liczba ta rosnie (a tak jest najczesciej) to liczba zadan przeliczonych rosnie szybciej niz server jest w stanie je doda do bazy statystyk (czyli odznaki czas przeliczen ilosc wu). Po prostu nie wyrabia sie server/baza. Nic nie ucieknie tylko potrwa ... Mozna ewentualnie Rysia poprosic zeby jakos to odetkal  :P

[stiven]

Ostatnio przetworzyłem z 40000 WU ALX'az, a przyrosło mi może z 30 godzin. CHORE!!!  :wth:

30 godzin CPU? Ten podprojekt jest NCI: non cpu intensive więc jak ma Ci przyrastać czas CPU? Co tu jest chorego wg Ciebie bo nie rozumiem. 

[Dario666]

Normalnie. FreeHal też jest NCI, a czas przyrasta zgodnie z czasem "Run Time", a nie "CPU Time". Mam ponad 1700 godzin w tym projekcie.
Po drugie w "Zadaniach" OProjectu widać (w załączonych plikach), że mam przetworzonych 10168 WU ALX'a , każda po 8 kredytów, czyli w sumie 81344 kredytów, a w "Participation Statistics", jak widać na zrzucie, jest 858 rezultatów za około 6864,000 kredytów. Czyli gdzie jest te ponad 70000 kredytów?

[mimeq]

tak jak pisalem, tu:

Kod [Zaznacz] Rozwiń

Over: 652 294

czyli w wynikach odeslanych a nie przetworzonych przez server i nie dodanych do statystyk  :ahoy:

[Rysiu]

Tak jak pisze mimeq.

Do tego CPU Time nie wzrośnie i tak. ALX nie wykorzystuje CPU. Rośnie za to Elapsed time.

[stiven]

A czy da się coś zrobić aby projekt przestał wysyłać te blokujące cały rdzeń próbki ALX? W preferencjach mam tylko Weird zaznaczone ale i tak je dostaję. Zastosowanie app_info wg informacji z forum powoduje przydzielanie zerowych punktów dla liczącego i dodatkowo dla jego wingmana.

[Dario666]

Już doszedłem do prawdy. Wg moich obliczeń projekt błędnie rozpoczął liczyć mi CPU_Time i Elapsed_Time od wartości 1 024 000 sekund (czyli 284,444 godzin) zamiast od ZERA. Wtedy od Elapsed_Time odejmując 284,444 i dzieląc przez liczbę WU otrzymujemy około 10,5 minuty na 1 WU, czyli tak jak jest w rzeczywistości.
@ stiven: Inną sprawą jest to, że serwery tego projektu są tak zarąbane, że ciężko z nimi współpracować i dlatego są takie opóźnienia w statystykach. Możliwe, że tak samo jest ze zmianą konfiguracji - dopiero po kilku godzinach lub dniach nie będzie pobierał ALXów.

[Dario666]

Nowe info:

OProject@Home: Powiadomienia z serwera
Weird Engine Odd needs 569.24MB more disk space. You currently have 898.33 MB available and it needs 1467.57 MB.

Weird Engine Odd ściąga na dysk, z serwera OProjectu, archiwum GZ o wielkości ponad 300 MB i potrzebuje 1,5 GB przestrzeni dyskowej. Chyba ich pogięło  :wacko:

[sknd]

mam pytanko: będą jeszcze ALX-y? daaawno nic nie było...

[Rysiu]

Trudno powiedzieć.

Mam spory problem. Posiadam program dotyczący hipotezy Riemmana.

Źródło to ZetaGrid:
http://www.zetagrid.net/zeta/sourcecode.html
http://www.zetagrid.net/zeta/ZetaGrid_0141.zip

Program po lekkich poprawkach bezproblemowo się kompiluje na Linuxie. Jest już napisany w sposób umożliwiający bezproblemowe zrównoleglenie na BOINC.

Cały zonk polega na tym, że nie wiem jak interpretować wyniki, które zwraca. Zapisuje wszystko do dwóch plików - .txt i .log. w .log znajdują się logi programu. Natomiast w txt wyniki jego działania.

Program ten powinien obliczać zera funkcji dzeta. Dla uruchomienia:

./zeta_zeros 0 1000

Wyliczy 1000 zer licząc od początkowego zera numer 0, a w pliku tekstowym zapisze wynik:

1.17.848
1.23.172
1.27.671
1.31.719
1.35.468
1.39
1.42.364
1.45.593
1.48.711
1.51.734
1.54.676
1.57.545
1.60.352
1.63.102
1.65.801
1.68.454
1.71.064
1.73.635
1.76.171
...

Wklejam tutaj jedynie wartości początkowe.

Właśnie z interpretacją tych wartości jest problem, ponieważ faktycznie pierwsze zero funkcji dzeta wynosi w przybliżeniu 1/2 + 14,134725i, drugie: 1/2 + 21,022040i, a trzecie: 1/2 + 25,010856i (są to liczby zespolone). Jak więc te wartości mają się do tych z pliku? Co tak naprawdę jest zapisywane w pliku i co tam właściwie w zapisie robią dwie kropki?

Program jest zbyt ciężki jak na moje umiejętności programistyczne tym bardziej, że jest dość skromny w komentarze i pewna jego część została przepisana do Asemblera.

Była próba kontaktu mailowego z administratorem (S. Wedeniwski) ZetaGrid ze strony Fundacji ale mimo upływu ponad miesiąca nie otrzymaliśmy odpowiedzi. Obliczenia można przenieść na BOINC co też chciałbym zrobić. ZetaGrid nie działa już od kilku lat.

Może ktoś potrafi pomóc?

[Dario666]

Może ktoś wie dlaczego nie chce mi ściągać WU z Shor's Algorithm. W logu jest napisane, że nie ma dostępnych zadań dla tego projektu, a w statusie projektu widać ponad 100 000 dostępnych WU Shor'a. O co chodzi???  :wacko:

[Rysiu]

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.

[gaballus]

nie ma problemu :)

[PoznanskaPyra]

Obigtest z 32 wątkami czeka na wu  8)

[patyczak]

Jeśli testy pojawią się w tym tygodniu to bardzo chętnie  :)

[Dario666]

Jak GSCE-SV może być tak źle zoptymalizowany, że na Linuxie liczony jest 2 godziny, a na Windows minimum 6 godzin.

[Rysiu]

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.

[Dario666]

Na Intelu 3470 3.2 GHz liczy ponad 9 godzin. To nie może być wina tylko obliczeń 32-bitowych.

[Rysiu]

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:

Kod [Zaznacz] Rozwiń

time env OMP_NUM_THREADS=X ./goldbach_odd 100000000209366024193 1000000000000000000000

Kod [Zaznacz] Rozwiń

time env OMP_NUM_THREADS=X ./goldbach_odd 100000000209366024193 10000000000000000000000

Kod [Zaznacz] Rozwiń

time env OMP_NUM_THREADS=X ./goldbach_odd 100000000209366024193 100000000000000000000000

Kod [Zaznacz] Rozwiń

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ć.

[mimeq]

cloud z ovh

GenuineIntel Intel(R) Xeon(R) CPU E5504 @ 2.00GHz [Family 6 Model 26 Stepping 5]

Boincowy benchmark:

Measured floating point speed     1993.56 million ops/sec
Measured integer speed             8116.8 million ops/sec

time env OMP_NUM_THREADS=4 ./goldbach_odd 100000000209366024193 1000000000000000000000
Thread 0: [100000000209366024193; 325000000156972613633]
Thread 1: [325000000156972613633; 550000000104579203073]
Thread 2: [550000000104579203073; 775000000052185792513]
Thread 3: [775000000052185792513; 1000000000000000000000]

real    0m1.655s
user    0m3.716s
sys     0m0.000s


time env OMP_NUM_THREADS=4 ./goldbach_odd 100000000209366024193 10000000000000000000000
Thread 0: [100000000209366024193; 2575000000156949020673]
Thread 1: [2575000000156949020673; 5050000000104532017153]
Thread 2: [5050000000104532017153; 7525000000052115013633]
Thread 3: [7525000000052115013633; 10000000000000000000000]

real    0m19.472s
user    0m38.894s
sys     0m0.008s

time env OMP_NUM_THREADS=4 ./goldbach_odd 100000000209366024193 100000000000000000000000
Thread 0: [100000000209366024193; 25075000000156964749313]
Thread 1: [25075000000156964749313; 50050000000104563474433]
Thread 2: [50050000000104563474433; 75025000000052162199553]
Thread 3: [75025000000052162199553; 100000000000000000000000]

real    1m40.793s
user    3m20.337s
sys     0m0.020s

[gaballus]

/proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz
stepping        : 7
microcode       : 0x28
cpu MHz         : 1600.000
cache size      : 3072 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave avx lahf_lm arat epb xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips        : 6185.92
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

włączone HT, dlatego testowałem na 2 i na 4 wątkach

time env OMP_NUM_THREADS=2 ./goldbach_odd 100000000209366024193 1000000000000000000000
Pom: 0 Przedzial: 449999999895316987903
Przedzial ost: 10728836057073
Thread 0: [100000000209366024193; 550000000104621146113]
Thread 1: [550000000104621146113; 1000000000000000000000]

real    0m1.056s
user    0m2.060s
sys     0m0.000s


time env OMP_NUM_THREADS=2 ./goldbach_odd 100000000209366024193 10000000000000000000000
Pom: 0 Przedzial: 4949999999895316987903
Przedzial ost: 118017196652776
Thread 0: [100000000209366024193; 5050000000104615903233]
Thread 1: [5050000000104615903233; 10000000000000000000000]

real    0m11.873s
user    0m23.640s
sys     0m0.000s


time env OMP_NUM_THREADS=2 ./goldbach_odd 100000000209366024193 100000000000000000000000
Pom: 0 Przedzial: 49949999999895316987903
Przedzial ost: 1190900802609807
Thread 0: [100000000209366024193; 50050000000104605417473]
Thread 1: [50050000000104605417473; 100000000000000000000000]

real    2m3.086s
user    4m3.248s
sys     0m0.000s


time env OMP_NUM_THREADS=2 ./goldbach_odd 100000000209366024193 1000000000000000000000000
Pom: 0 Przedzial: 499949999999895316987903
Przedzial ost: 11919736862180120
Thread 0: [100000000209366024193; 500050000000104626388993]
Thread 1: [500050000000104626388993; 1000000000000000000000000]

real    21m18.234s
user    42m7.112s
sys     0m0.004s



time env OMP_NUM_THREADS=4 ./goldbach_odd 100000000209366024193 1000000000000000000000
Pom: 0 Przedzial: 224999999947658493951
Przedzial ost: 5364418028536
Thread 0: [100000000209366024193; 325000000156972613633]
Thread 1: [325000000156972613633; 550000000104579203073]
Thread 2: [550000000104579203073; 775000000052185792513]
Thread 3: [775000000052185792513; 1000000000000000000000]

real    0m0.574s
user    0m1.428s
sys     0m0.000s



time env OMP_NUM_THREADS=4 ./goldbach_odd 100000000209366024193 10000000000000000000000
Pom: 0 Przedzial: 2474999999947658493951
Przedzial ost: 59008598326387
Thread 0: [100000000209366024193; 2575000000156949020673]
Thread 1: [2575000000156949020673; 5050000000104532017153]
Thread 2: [5050000000104532017153; 7525000000052115013633]
Thread 3: [7525000000052115013633; 10000000000000000000000]

real    0m12.168s
user    0m32.480s
sys     0m0.000s



time env OMP_NUM_THREADS=4 ./goldbach_odd 100000000209366024193 100000000000000000000000
Pom: 0 Przedzial: 24974999999947658493951
Przedzial ost: 595450401304903
Thread 0: [100000000209366024193; 25075000000156964749313]
Thread 1: [25075000000156964749313; 50050000000104563474433]
Thread 2: [50050000000104563474433; 75025000000052162199553]
Thread 3: [75025000000052162199553; 100000000000000000000000]

real    3m56.885s
user    10m32.652s
sys     0m0.000s


time env OMP_NUM_THREADS=4 ./goldbach_odd 100000000209366024193 1000000000000000000000000
Pom: 0 Przedzial: 249974999999947658493951
Przedzial ost: 5959868431090059
Thread 0: [100000000209366024193; 250075000000156954263553]
Thread 1: [250075000000156954263553; 500050000000104542502913]
Thread 2: [500050000000104542502913; 750025000000052130742273]
Thread 3: [750025000000052130742273; 1000000000000000000000000]

real    24m3.202s
user    58m8.736s
sys     0m0.044s