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

Konserwacja gg@h cpu

Tutaj jest dłuższa historia.

Wczoraj chciałem przenieść GG@H CPU na fizyczną maszynę z dyskiem SSD, ale jako maniak robienia kopii… tak, tak robiłem backUp i umarła maszyna VPS na której był serwer/projekt. Musiałem na szybko przenieść dysk maszyny do siebie na komputer, odpalić maszynę VirtualBox z tym dyskiem, naprawić dysk i odpalić projekt na wspomnianym VirtualBoxie.

Wszystko chodziło bez problemu i dalej pewnie by tak było, ale nie taki był cel całej operacji… jednak komputer roboczy czasami się wiesza i jest restartowany. Dlatego po wysłaniu wszystkich zadań w kolejce i odebraniu ponad 95% z nich zatrzymałem serwer celem podjęcia odpowiednich kroków:

  1. przeniesienia maszyny z VirtualBoxa na fizyczny sprzęt
  2. dopasowanie rozmiaru partycji do wielkości dysku
  3. małe podrasowanie mysql i apache2
  4. uruchomienie pamięci tymczasowej
  5. uruchomienie projektu boinc GG@h CPU
  6. wygenerowanie zadąń do stress testu: jedna seria 25,000 zadań i druga się generuje w ilości 1,000,000 tasków

Całość przeszła w miarę bez stresu i oby tak pozostało, bo mam co robić oprócz użerania się z serwerami 🙂