Boinc update #2

  1. Komputer  analizujący dostał spooorej zadyszki…  po wyłączeniu wszelkich skryptów działających w tle i odpaleniu SMART’a mogę uznać, że ten dysk jest w zasadzie martwy <- nie wspominając o odgłosach jakie zaczął wydawać
  2. W nawiązaniu do pkt.1 zmieniłem skrypty wszystkie analizujące aby pobierały pliki do sprawdzenia bezpośrednio z macierzy dyskowej i od razu wrzucały je z powrotem na macierz <- etap tymczasowego przechowywania danych na dysku w kompie pomocniczym wyleciał… jest za duże ryzyko utraty danych.
  3. Jutro rozglądnie się za możliwością podpięcia pod ten sprzęt dysku SSD, a podobno można to zrobić za pomocą specjalnego konektora… tylko czy opłacać sią kupować dysk SSD skoro notabene dysk i tab będzie podpięty pod ATA. Drugim pomysłem do sprawdzenia jest podpięcie nowego dysku (w sensie jakiegoś z zapasowych leżących na półce) w kieszeni pod USB tak jak to mam w drugiej testowej maszynie. Teoretycznie wydajność byłaby trochę marna, ale skoro dysk nie będzie przechowywał i obracał gigami danych na godzinę to może być nawet dobre rozwiązanie.
  4. Aktualne kolejki do analizy to: (oczywiście przez te zaległości obrywa się bazie danych z wynikami… ok.75% plików pozostawia swój wpis w bazie)
    1. GG@h NCI : 12kk plików <- w sensie 12 milionów plików na macierzy i 2 miliony do wysłania na nią
    2. GG@h CPU: 1 milion (1kk) plików do analizy i 10k do przesłania do archiwum na macierzy

Boinc update #1

  1. GG@h NCI ma się dobrze, choć zaległości nie zmniejszają się, a wręcz rosną <- wychodzi, ze teraz jest tego ok.10kk plików.. dramat.
  2. GG@h CPU już ma się dobrze <- zapomniałem, ze na stacji dysków przenosiłem katalogi NFS z jednego wolumenu na drugi przez co nei przepiąłem katalogów na komputerach, które ich używają. W tej chwili sytuacja opanowana, zaległość wynosi  375k plików do analizy, ale do rana powinno zejść.
  3. GG@h CPOU, ze względu na ilość spływających wyników musiałem uruchomić drugi walidator, żeby nie robić zbyt dużych kolejek. Ciekawe co będzie przy kilku tysiącach hostów, albo co lepsze przy okazji projektów miesiąca lub wyścigów… nawet nie chce o tym myśleć
  4. Z przykrością stwierdzam, że mój komputer analizujący dane, generujący zadania itp/itd doszedł do granic swojej wydajności <- jak w większości takich przypadków uchem igielnym jest… tadam… dysk <- nie dość, że na interfejsie ATA (który jest już tylko w muzeach) to jeszcze ma 5400obr i w zasadzie zachowuje się jakby miał zaraz umrzeć.  Muszę sprawdzić czy mogę tam wrzucić dysk SSD na SATA zamiast DVD

No to jazda…

Automatyczny analizator dla htest 2.0.0 zrobiony i odpalony, skrypty automatyzujące pracę GG@H CPU odpalone, masowy generator odpalony….

Nic tylko czekać aż coś się zdupi <- to nie kwestia czy, ale kiedy… tak wynika z mojego doświadczenia.

Dodatkowo cały czas odkopuje się z zaległości w analizie wyników z GG@H NCI po  sobotnim krachu skryptów (jest tego jeszcze ok.1,2kk plików), nie mówiąc o starych zadaniach z htest (tu jest więcej bo 2,5kk). Mam nadzieję, ze teraz będzie chwila wytchnienia przy pracach nad htest’em.

Htest_64bits 2.0.0

Nowa aplikacja to mała rewolucja. Zadania będą trwały średnio 25 minut (zależnie od CPU), analiza wyników będzie banalna <- bo rezultatem jest plik tekstowy nie binarny, mający 3-4 zmienne a nie ponad 100 😀

Analiza poprzednich zadań z wersji 1.0.6 jest na poziomie 60% i działa sobie w tle na laptopie analizującym dane.

50% analizy dla 1060

W tej chwili w bazie znajduje się 3,5kk wpisów statystycznych z wyników dla wersji htest_64bits 10.60 do tego ok.30k plików było błędne. Dzisiaj w  nocy powinna skończyć się analiza zaległych serii 4,4kk, i rozpocząć aktualna seria 3kk. Dodatkowo zaczyna pracować skrypt zliczający statystyki dla całych serii zadań w boinc ( na razie było 10 serii).

Czekam teraz na informacje o Rysia o nowej wersji jaką mam udostępnić i zadań jakie mam generować <- były zmiany zarówno w plikach wejściowych jak i wynikach.

Postępy analizy htest_64bits

Aktualny postęp to 445k z 4kk <- nie jest to o czym marzyłem po 24h pracy skryptów, ale zawsze może być gorzej. Zobaczymy co będzie dalej.

Dodatkowo musiałem wygenerować 3kk nowych zadań więc pula wyników będzie wynosić 7,4kk.

Analizator htest_64bits

Analizatory zapuszczone, statystyki są zapisywane do bazy danych z każde pliku wynikowego z projektu boinc. Tworzenie tego skryptu szło mi jak krew z nosa i zajęło chyba 3-4 wieczory.. większość polegała na tępym wpatrywaniu się w kod i kompletnej niemocy w zrozumieniu tego co trzeba zrobić. Dopiero w piątek doznałem olśnienia i skończyłem prace.

 

Wydajność demonów

Jako, że aplikacja htest_64bits przekroczyła 100,000 zadań w toku i projekt zaczął mieć poważne kolejki przy walidacji zadań postawiłem uruchomić po 4 demony z każdego, który nie wydal <- na razie daje radę.

Jednym z najbliższych kroków jakie podejmiemy z Rysiem to wydłużenie czasu pracy 1 zadania z 1-2 minut do 10-15 minut <- to zdecydowanie odciąży ruch na serwerze.

Temperatury na procesorze c.d.

Z obu laptopów odkręciłem panele z obudowy nad wiatrakami przy CPU i temperatury spadły średnio o 20 stopni… na początek świetny wynik, ale pasty na prockach definitywnie są do wymiany.

Problemów ciąg dalszy <- temperatury na procesorze

Tym razem sprzęt na którym stoi projekt GG@h CPU daje mi strasznie popalić…

Temperatura na procesorze według czujników cały czas oscyluje w granicach 95-100 stopni Celsjusza co jest kompletną bzdurą i masakrą <- przy założeniu że w zasadzie tylko 1 rdzeń/2 wątki są obciążone….

W zasadzie to na GG@h NCI temperatura wynosi ponąć 70-80 stopni. Jedyne co podejrzewam to wypalona pasta na procesorach <- w zasadzie jestem prawie pewien, że tej pasty już tam nie ma.

eh… nigdy nie ma tak, żeby wszystko grało jak należy <- no cóż wyzwania są potrzebne 🙂 muszę jak najszybciej kupić pastę na cpu i się z tym pobawić.