BOINC@Poland

Liczymy jedynie podprojekt:
Generalized Cullen/Woodall Prime Search LLR (GCW)
start:
2017-08-20 18:00
meta:
2017-08-23 18:00
Tzn. ruszamy po dwudziestej czasu polskiego w najbliższą niedzielę. Rozumiem, iż wakacyjne rozleniwienie deko nas dopadło, lecz czas z tym skończyć. Trza zewrzeć szeregi, bo tradycja dobrych występów Boinc@Poland w primegridowych regatach przecież zobowiązuje.

Ściganie w PG? Super :boing:
Proszę przypomnieć sklerotykom przed startem :attack:

U a ja na 100% nie wystartuje  :(

Cytat: necavi w 16 Sierpień 2017, 17:36
Ściganie w PG? Super :boing:
Proszę przypomnieć sklerotykom przed startem :attack:

Przypomnę o wyścigu w niedzielny poranek. Znając życie odezwę się także w chwili startu. Upraszam o powiadomienie liczydłowych niezaglądających zbyt często na forum.

Do startu pozostało niecałe osiem godzin. Południe już minęło, więc ponawiam apel o przygotowanie się.

No to ruszylim.  :attack:

 I ja też :attack:

Z opoznieniem ale cos policze  :p_arr:

Wiosłujemy...

Dopięty. Xeon zdąży coś przeliczyć.
PG podaje na stronie

CytatRecent average CPU time: 22:21:26

Rzetelnie uprzedzam, że gdy poprzednio liczyłem na Pentiumie i Phenomie GCW LLR to na przeliczenie próbki schodziło dwie doby ciągłej pracy.
Jeśli ktoś próbuje liczyć na słabszych sprzętach niech lepiej da spokój.

u mnie i tak liczy "wielordzeniowo" :]

A na głównej brak info o wyścigach :wth:

Cytat: necavi w 21 Sierpień 2017, 16:32
A na głównej brak info o wyścigach :wth:

A owszem. O wyścigach nie pisuję, KrzyszP pisze o Universe, kilka innych osób mimo uprawnień napisało po 1 newsie.
Ktoś chętny do pisania o wyścigach?

Najkrótsza próbka mieliła się u mnie dokładnie 46:38:38 a regaty trwają tylko trzy doby. Normalnie jakieś jajca prostokątne. Co do pisania o wyścigach, to ograniczam się obecnie do pisania na forum, ponieważ nie wiem, czy wrzucanie tego na główną w ogóle ma sens. Czytaj, spotkałoby się z jakimś zainteresowaniem, czyli większym zaangażowaniem naszych załogantów w ściganie. Nie orientuję się obecnie, jak z redagowaniem takich informacji poradziłby sobie gadacz. Na zakończenie wypada jeszcze odnotować pewien mały drobiazg. Mianowicie uprawnień do zamieszczania wieści nie posiadam. To tak celem wyjaśnienia dla kolegi zaskoczonego tym, czemu cała akcja pt. mobilizacja primegridowa bazuje u nas jedynie na utworzeniu kolejnego wątku.

O ile dobrze znalazłem to liczysz na i3-4170. Jeśli liczysz klasycznie a nie wielowątkowo to upewnij się, że nie liczysz na wszystkich wątkach naraz. Dla i3 i podprojektów dużych optymalne wykorzystanie wątków to 2 max 3. Przy 4 próbkach jednocześnie (100% of the CPUu) czas przeliczania gwałtownie rośnie. W końcu ten procesor ma 2 rdzenie fizyczne. Dla PG najprościej wyłączyć HT bo więcej z niego szkody niż pożytku.   

Re: newsy o wyścigach - ja też nie mam żadnej pewności, że to co pisuję ma jakikolwiek sens, bo równie dobrze mógłbym pisać takie wiadomości na forum. Ale zwyczajnie lubię pisać newsy na głównej i dlatego to robię.
Re: HT w PG - HT ma sens przy liczeniu sieve.

Racja, racja.  :parrrty: Mój wywód dotyczył podprojektów LLR.

No to po herbacie, bo odpaliłem liczenie samego primegrida, czyli cztery próbki na raz. Rozumiem, że optymalnie by liczył mogąc mielić na raz dwa zadania. Taka zasada, tyle próbek ile rdzeni fizycznych. Jak przydzielić projektowi maksymalną ilość uruchamianych jednocześnie aplikacji? Przypisałbym wówczas dwie Primegridowi i miałbym spokój. Wyłączenie ht to dla mnie kompletna nowość. Generalnie dotyczy to jednego boincowego projektu a ściślej pisząc jego podprojektów i tu uwaga, również nie wszystkich. Gdyby można było wykonać tą sztuczkę poprzez jakiś plik konfiguracyjny umieszczany w boincowym katalogu, to reflektuję. Odrzucam pomysły typu ingerencja w ustawienia systemowe całej maszyny.

Oj przydałby się chyba mały poradnik edycji app_config.xml :attack:

Już za późno na zmianę ale na przyszłość :

<app_config>
   <app>
      <name>llrGCW</name>
      <fraction_done_exact/>
      <max_concurrent>1</max_concurrent>
   </app>
   <app_version>
       <app_name>llrGCW</app_name>
       <cmdline>-t 2</cmdline>
       <avg_ncpus>2</avg_ncpus>
   </app_version>
</app_config>

Jedna próbka na projekt GCW LLR na dwóch rdzeniach. Wrzuć do katalogu danych danego projektu i przeładuj konfigurację. Podobnie robisz dla innych podprojektów - zmień tylko nazwę w tagu <name> apka</name> oraz  <app_name>apka</app_name>

Lista aplikacji:llrTPS (SGS)
llrWOO
llrCUL
llr321
llrPSP
pps_sr2sieve
llrPPS
ap26
llrSOB
trp_sr2sieve
llrTRP
genefer (GFN 21)
genefer_wr (GFN 22)
llrPPSE
llrSR5
llrESP
llrMEGA (PPS-MEGA)
genefer15
genefer16
genefer17low
genefer17mega
genefer18
genefer19
genefer20
gcw_sieve
llrGCW


Alternatywą dla wyłączenia HT w Biosie jest ustawienie w BOINC żeby używał 50% dostępnych CPU. Z tego co czytałem na forum PrimeGrid w ten sposób traci się jednak część mocy CPU (bodajże 10%) bo procesy nie są "przypięte" do fizycznych rdzeni. Wydaje mi się że to dotyczyło głównie Windows, Linux radzi sobie z tym lepiej.

potestuję te rozwiązania po zawodach. Dzięki za wszelkie informacje.

Jako, że do końca mało czasu zostało a zapewne część z nas ma próbki które nie zmieszczą się w limicie czasu śpieszę przypomnieć, że app_config.xml można edytować w trakcie liczenia i nie powoduje to wywalania się zadań.
Także śmiało modyfikujcie, liczcie multi aby się wyrobić.

Na szczęście zdołałem już wszystko odesłać. Przetwarzanie znacznie przyspieszyło, gdy pozostały dwie z czterech pobranych próbek. Dlaczego Primegrid domyślnie się tak nie ustawia, aby llry uwzględniały ilość rdzeni fizycznych? Przecież boincowy menedżer widzi typ procesora a pomimo tego optymalizować prędkość mielenia trzeba ręcznie.

I żeby nie było, że wyścig się skończył a tu nie wiadomo jak poszło to cytuje wyniki.

Zespołowo:
1   Aggie The Pew          14735673.31
2   SETI.Germany         11729492.38
3   Czech National Team  10680907.89
.
7   BOINC@Poland         2552410.42

Indywidualnie z B@P:
7   Daniel            1723453.78
50   Aleksander      346087.01
110   centylion torun   135945.06
118   mimeq      126058.24
134   stiven      102578.20
163   RAD-Poland       74872.24
246   necavi       27184.46
279   Ufol               16231.42

Podsumowując wyścig był ciężki, próbki liczyły się (przynajmniej u mnie) przeszło dwa dni i nie wszystkie zostały odesłane w czasie, jedną próbkę jestem pewien, że przeliczyłem w czasie.                                                                                                                                                                                                                                             e.

Przy tak długich zadaniach lepiej jest liczyć jedno zadanie na kilku wątkach np. na 4. Czas liczenia zadania się skraca, więc jest większa szansa że uda się odesłać więcej zadań niż licząc każde zadanie na 1-nym wątku.