Tworzenie projektu... czyli powstanie i ewolucja Enigma@Home

[Bober]

Przypuszczam, że już mało kto ma "nieprzeliczone" zadania  :P
Mam zatem nadzieję, że to "tylko" zasilacz.

[TJM]

Po południu brachol zajrzy w ten sprzęt i podmieni zasilacz, więc pewnie wieczorem będę wiedział co i jak.

Oprócz problemów sprzętowych serwer miał też ostatnio problemy natury softwarowej - z jakiegoś powodu część całkiem poprawnych zadań była odrzucana na dalszych etapach weryfikacji. Problem ten istniał już w styczniu ale teraz jakoś przybrał na sile, doszło do tego, że niektóre zadania były wysyłane po 4 razy zanim wynik 'przeszedł', a ogólna liczba takich błędów dotyczyła jakichś 15% zadań, co jest niedopuszczalne. Chciałem zatrzymać generowanie nowych zadań do czasu wyjaśnienia tego zjawiska, ale awaria mnie ubiegła :/

[emik]

na szczęście to chyba tylko zasilacz - serwer wstał i odebrał przeliczone zadania.

[TJM]

No nie do końca, bo po zmianie zasilacza sprzęt coś nie chciał ruszyć, ale w końcu się odpalił. Mam nadzieję, że to zły kontakt w jakimś złączu a nie szykująca się gruba awaria.

[Troll81]

lepiej pohuchac na zimne. może przesiadka na maszynke wirtualną i codzienny backup?? w razie W zmienisz serva w kilka dni :D

[TJM]

Pod tym względem maszyna wirtualna wcale nie jest lepsza od zwykłego kompa, backupy robią mi się na bieżąco co 12h. Na dodatek wydajność takiej maszyny blado wypada na tle zwykłego OSa odpalonego na tym samym sprzęcie.

[TJM]

Wreszcie chyba poprawiłem przyczynę oznaczania poprawnych zadań jako błędne. Prosty błąd a spędziłem kilkanaście godzin szukając go.
Jak wszystko będzie ok odpalę z powrotem zatrzymany aktualnie automatyczny generator zadań.

[lukaszde]

Blad z pobieraniem nowych probek. Po przywroceniu serwera do zycia od kilku dni nie otrzymalem zadnej probki. Pojawial sie komunikat "no work sent" Usunalem pliki ciphertext2, wrapper, windows_enigma_intel.
Po zaktualizowaniu polaczenie z serwerem, automatycznie zostaly pobrane 4 usuniete pliki oraz dostalem probki do liczenia. Czyzby jakis blad zwiazany z padem serwera ? Czy ktos moglby potwierdzic ?

[TJM]

Raczej jakiś tymczasowy problem z feederem, on tak lubi zamotać wysyłanie jeśli były jakieś przestoje - szybko zapełnia kolejkę priorytetowymi zadaniami i jeśli łączący się komp nie spełnia warunków na priorytetowe (RAC 100+ i turnaround < 3 dni) nie dostaje nic.

[TJM]

Problem z feederem po raz kolejny trochę załagodzony przez dalsze zwiększenie ilości zadań jakie na raz widzi, trochę kosztem wydajności ale póki co zapas szybkości serwera jest tak duży, że nie ma się czym przejmować.

Problemy z odpalaniem serwera przy zimnym starcie to jednak nie wina płyty, tylko dysków i zasilacza - nowy zasilacz czasami nie ma siły rozkręcić na starcie 6 dysków, pewnie dlatego że przy rozkręcaniu talerzy każdy ciągnie ponad 20W - to daje ze 120W na same dyski.

Btw dziś w godzinach wieczornych pewnie pojawią się nowe rodzaje workunitów, wrapowane z 'starego' i 'nowego' serwera M4 (obecne są z 'alpha' serwera). Póki co jestem na etapie kalibracji punktów, nie wiem czy dam radę się na wieczór wyrobić.


Jeśli ktoś z was dostanie zadania z serii awgly100 dajcie znać czy wszystko gra - czas przeliczania jest około 1.38x dłuższy od hceyz72, punktacja na początku może trochę nie trzymać się kupy, ale sama się ustawi po pierwszych kilkuset zadaniach.


Edit2: Jednak czasy są trochę nieliniowe, zadania awgly100 typu 3 trwają blisko 2 razy dłużej od hceyz72/3. Jak na razie wszystko wygląda ok, póki co awgly100 przeliczane są przez testową aplikację (w zasadzie aplikacja ta sama ale z ulepszoną konfiguracją, znacznie zmniejsza ilość ściąganych z serwera plików).

Natknąłem się wczoraj na kolejne problemy:
- szybkość odpowiedzi serwera M4 ogranicza prędkość ściągania zadań. Próbowałem to przeskoczyć przez jednoczesne ściąganie wieloma wątkami i daje to jakieś efekty, ale i tak na razie nie mogę przeskoczyć progu 20k ściągniętych zadań/dzień, głównie dlatego, że czasami coś się zamula i serwer odpowiada bardzo wolno. To tylko niecałe 50% więcej od aktualnej szybkości projektu, więc jeśli nagle przybędzie dużo hostów mogą pojawić się braki w dostawach. Zobaczymy jeszcze jak będzie przy hurtowym pobieraniu zadań z dwóch podserwerów.
Ten sam problem istnieje z odsyłaniem zadań, ale to nie ma wpływu na działanie całości, deadline na serwie M4 jest bardzo długi (chyba kilka miesięcy) więc nie zaszkodzi zadaniom jeśli poleżą w kolejce przed odesłaniem.

Nawiasem mówiąc, po półrocznej przerwie widać niezły wzrost prędkości przeciętnego hosta w projekcie. Hostów póki co mniej niż było, a średnia prędkość wychodzi dużo wyżej niż w lutym. Przy takiej prędkości zadań z serii hceyz72 starczy max na 3-3,5 miesiąca, dlatego muszę przyspieszyć rozbudowę serwera o obsługę kolejnych podserwerów.

Linki do rezultatów i statystyk prędkości 'new' serwera M4:

http://www.bytereef.org/new-server-results.txt
http://www.bytereef.org/new-server-stats.txt

Jak widać średnia prędkość (rate) już zaczęła się podnosić, mimo że zadania awgly100 to obecnie mniej niż 1% wszystkich wysyłanych przez Enigma@Home.

dla porównania rezultaty i statystyki 'alpha' serwera:

http://www.bytereef.org/alpha-results.txt
http://www.bytereef.org/alpha-stats.txt

[TJM]

Trzeba chwilowo jednak zatrzymać zadania z serii awgly. Przyczyny: 1. Pomimo, że są na pewno dłuższe u niektórych przeliczają się szybciej (muszę to jeszcze raz obadać), 2. zadania wysypują się po  dotarciu do hostów które mają zainstalowaną zoptymalizowaną aplikację. Nic dziwnego, bo app_info.xml ma wpis tylko ze starą aplikacją - nowej jeszcze nie było kiedy plik był przygotowywany. Myślałem, że boinc sam rozkmini które aplikacje ma klient, a jednak nie :D

[Thot]

Podobny problem mają w S@H. Trzeba ręcznie dopisywać Astropulse do optymalek.

[TJM]

W przypadku E@H rozwiązaniem jest rezygnacja ze starej aplikacji i przepisanie starych zadań pod nową, która jest w stanie obsłużyć wszystkie typy zadań (w starej pliki zadań są zintegrowane z aplikacją). To niestety musi zaczekać na któryś z nadchodzących weekendów, bo takie uaktualnienie wymaga opróżnienia kolejki zadań na serwerze i dość długich testów.

Edit: potrzebne też będą oczywiście nowe pliki app_info

[TJM]

Od paru dni trwa mały stress test serwera, wyłączyłem automatyczne czyszczenie bazy i dodatkowo pozwoliłem na naściąganie work unitów do oporu (100,000 gotowych do wysłania na serwerze i 50,000 w lokalnym buforze M4 wrappera). Oprócz tego specjalny skrypt symulujący prędkość odsyłania zadań około 10 razy większą niż obecna. Póki co wszystko wygląda bardzo dobrze, chociaż widać, że dźwigając ogromne zapasy zadań serwer znacznie zwalnia i średnie obciążenie rośnie:



Jednak standardowe ustawienia buforów są dalekie od tych wyśrubowanych - 5000 zadań gotowych do wysłania i [prędkość*10] (gdzie prędkość to aktualna średnia prędkość wszystkich podłączonych komputerów przeliczona na Athlony 1400) w lokalnym buforze, po to żeby w razie potrzeby były zadania na wypadek krótkiej przerwy w łączności z projektem M4 albo wbicia kogoś z mocnymi hostami (są kompy które potrafią wyssać po 1000 WU z serwera w ciągu paru minut  ;D)

Póki co cała automatyka serwera działa bardzo dobrze, jeśli tak dalej pójdzie to w październiku kiedy wrócę na stałe do domu będę mógł na spokojnie zająć się poprawianiem wrappera, bo problemy z nim związane ciągną się nie poprawione do tej pory od samego startu projektu.

[Pigu]

można na ten moment mieć optymalki, czy będzie sypać errorem?

[TJM]

Można, ale najlepiej byłoby dopisać do app_info drugą aplikację, wtedy w razie trafienia zadania awgly100 nie sypnie się ono (chociaż na chwilę obecną krążą tylko pojedyńcze zadania, mniej niż 0.1% całości).

[Pigu]

jak się ją dopisuje?  ;D

[TJM]

Tak samo jak tą pierwszą %-) Nie pamiętam dokładnie jak to się robiło, ale po obiedzie spróbuję podłubać.

[Thot]

Dla AstroPulse trzeba dokleić coś takiego:

<app>
<name>astropulse</name>
</app>
<file_info>
<name>astropulse_4.35_windows_intelx86.exe</name>
<executable />
</file_info>
<file_info>
<name>libfftw3f-3-1-1a_upx.dll</name>
<executable />
</file_info>
<file_info>
<name>ap_graphics_4.35_windows_intelx86.exe</name>
<executable />
</file_info>
<app_version>
<app_name>astropulse</app_name>
<version_num>435</version_num>
<file_ref>
<file_name>astropulse_4.35_windows_intelx86.exe</file_name>
<main_program />
</file_ref>
<file_ref>
<file_name>libfftw3f-3-1-1a_upx.dll</file_name>
</file_ref>
<file_ref>
<file_name>ap_graphics_4.35_windows_intelx86.exe</file_name>
<open_name>graphics_app</open_name>
</file_ref>
</app_version>

Więc może tu podobnie tylko zmienić nazwy aplikacji. I trzeba ręcznie wrzucić pliki aplikacji, bo podobno sam nie ściąga. Na forum SETI piszą, że działa.

[TJM]

Tu będzie trochę inaczej, bo obie aplikacje używają tych samych plików, jak na razie mam jakieś konflikty i BOINC kasuje mi pliki starej aplikacji po dopisaniu nowej do .xmla.
Stara aplikacja ma ciphertext i słowniki zintegrowane (są częścią aplikacji), nowa to tylko wrapper, job.xml i sam exek - reszta przychodzi z zadaniem, a ustawienia template'ów zadań po stronie serwera zapobiegają ściąganiu w kółko tych samych plików. Powoli muszę myśleć o przełączeniu także zadań starego typu pod nowa aplikację, ponieważ jest bardzo uniwersalna - jakiekolwiek zmiany w plikach, dodawanie zadań nowego typu itp wymagają tylko kosmetycznych zmian w generatorze zadań, podczas gdy starą aplikację trzeba było wypuszczać jeszcze raz z nowym numerem wersji...

[TJM]

To powinno działać:

http://plikens.no-ip.net/649xcmg88/apptest02.zip

exeki trzeba wybrać stare z tego tematu:

http://www.enigmaathome.net/forum_thread.php?id=17

teraz tylko pozostaje cierpliwie czekać na zadanie typu awgly100 żeby sprawdzić, czy z takim app_info ruszy (powinno).

Btw, umie się ktoś z was posługiwać kompilatorem Intela pod windą ? Patrząc na przyrost szybkości pod linuksem (nawet 30% szybciej od gcc) myślę że warto by spróbować także windowsowe aplikacje przekompilować i zobaczyć co z tego wyniknie.

EDIT: Ciekawe czy można jakoś wymusić wysłanie określonych zadań do jakiegoś hosta, bo przy obecnej ilości zadań awgly100 można na jedno pewnie nawet tydzień czekać...

[buninek]

Pod linuksem owszem używałem.
Chyba zachodzi spora analogia.
Tylko uwaga we wcześniejszych wersjach intel celowo blokował procesory AMD. (a to wredota!)
Trzeba było używać patchy, aby to odblokować.

[TJM]

Wersja której używam generuje kod działający bezproblemowo na procesorach AMD, przyrost prędkości nie jest tak duży jak dla proców Intela ale nadal wychodzi trochę lepiej od gcc.

Pod Windowsem próbowałem już kilku kompilatorów i wynikowy exek wychodzi prawie zawsze gorszy od tego ze starej wersji gcc, dlatego chciałem spróbować z kompilatorem Intela, ale coś nie mogę go rozgryźć.

Kombinować warto, bo obecnie mój stary testowy komp z Tualatinem 1.3 i linuksową aplikacją wyciska prędkość zbliżoną do jednego rdzenia Athlona 64 x2 4200+ pod Windows...

[Pigu]

zdaje się, że takie zadania nie tyle nie ruszają, co się nie pobierają:

2008-08-04 00:54:10|Enigma@Home|[error] State file error: missing application enigma_m4_2
2008-08-04 00:54:10|Enigma@Home|[error] Can't handle task awgly100_1_1142395_r0 in scheduler reply
2008-08-04 00:54:10|Enigma@Home|[error] State file error: missing task awgly100_1_1142395_r0
2008-08-04 00:54:10|Enigma@Home|[error] Can't handle task awgly100_1_1142395_r0_0 in scheduler reply

[TJM]

Pobierać na pewno się pobierają, problem leży w tym 'missing app'.

EDIT: dziś już nic nie wymyślę, czas na pociąg i wracać do roboty. Może znajdzie się wolny czas w tygodniu to pokombinuję. Mam nadzieję, że nic mi nie padnie w najbliższym czasie, bo następny planowany wyjazd za 2 tygodnie.

[Pigu]

czyli jak? powinny się pobrać i nie dać przeliczyć?

[TJM]

No właśnie nie wiem do końca co jest grane. Same zadania na pewno są dobre, na kompach bez zoptymalizowanej aplikacji działają. Po wrzuceniu app_info jest właśnie ten błąd, BOINC nie widzi drugiej aplikacji i odrzuca zadania.

EDIT: sprawdzałeś na plikach z poprzedniej strony ?

[Pigu]

ni  :)

[TJM]

No to właśnie tam jest tem poprawiony i teoretycznie dobry xml, reszta plików też dorzucona tylko główny exe trzeba dobrać.

[Pigu]

wgrałem - jak nic czerwonego w wiadomościach nie wyskoczy przez tydzień to wszystko ok?  :P

[TJM]

Wszystko ok będzie jak zobaczysz jakieś przeliczone zadania z serii awgly100 %-)

[Thot]

To chyba działa. Mam pobraną jednostkę awgly100 i czeka w kolejce zadań. Przedtem nawet nie pobierało.

2008-08-05 06:10:55|Enigma@Home|Scheduler request succeeded: got 1 new tasks
2008-08-05 06:10:58|Enigma@Home|Started download of 00hc_wu_1118823_r0
2008-08-05 06:10:58|Enigma@Home|Started download of m4_awgly100_1
2008-08-05 06:10:59|Enigma@Home|Finished download of 00hc_wu_1118823_r0
2008-08-05 06:11:00|Enigma@Home|Finished download of m4_awgly100_1

Dam znać jak przeliczę.

[TJM]

Zwróć też uwagę na czas przeliczania, powinien być wyraźnie dłuższy od zadań hcey72 tego samego typu.


W październiku jak wrócę na stałe do domu konieczny będzie krótki przestój w pracy serwera, będę musiał zapodać co najmniej ze dwa duże dyski w RAIDzie, bo z tego co widzę przy dużym obciążeniu serwer po prostu nie nadąża zapisywać plików na dysku, na razie to nie problem ale kiedyś może dać się we znaki.

[Thot]

Jednostka przeliczona, odesłana, kredyt przyznany  :)
http://www.enigmaathome.net/workunit.php?wuid=105671
Co do czasu przeliczania, trudno oceniać po jednej jednostce. Trafiła mi się jednostka awgly100 typ 2 a przeliczała się mniej więcej tyle co hceyz72 typ 3.

[TJM]

Jednostka przeliczona, odesłana, kredyt przyznany  :)
http://www.enigmaathome.net/workunit.php?wuid=105671
Co do czasu przeliczania, trudno oceniać po jednej jednostce. Trafiła mi się jednostka awgly100 typ 2 a przeliczała się mniej więcej tyle co hceyz72 typ 3.

Takiego czasu właśnie należy się spodziewać, wygląda na to że wszystko ok.


EDIT: testuję teraz app_info na linuksie, jak wszystko będzie działać wrzucę info na forum projektu i odkręcam kranik z zadaniami awgly.

[TJM]

Niespodziewany wolny weekend = drobne zmiany po stronie serwera projektu.
Kilka minor-bugfixów - usunąłem resztki slashów i backslashów 'walających' się po podstronach, profilach itp (to wina upgrejdu kodu php), podłubałem trochę w bazie i skryptach generujących wewnętrzne statystyki żeby trochę odciążyć serwer (co od razu widać bo server-status przelicza się w sekundę zamiast w 15s %-)). Serwer póki co chodzi stabilnie, więc chyba czas po zmiany w kodzie klienta - czas w końcu dorobić wskaźnik postępów przeliczania do wrappera  :D

EDIT: no to mam wrappera który poprawnie pokazuje postęp w procentach (liniowo ze skokiem 0.2%) i na dodatek zapisuje poprawnie czas CPU przy wyjściu. Jeszcze go trochę potestuję u siebie a potem udostępnię tymczasowo jako dodatek do zoptymizowanej aplikacji w celu dokładniejszego przetestowania.


EDIT2:
Testowa wersja wrappera !!! tylko do użytku w połączeniu z app_info.xml !!!

http://plikens.no-ip.net/652xiot1w/wrapperwindowsintelx86.zip

Wypisuje trochę informacji do stderr więc jeśli zauważycie coś dziwnego, dajcie od razu link do rezultatu, łatwiej będzie znaleźć błędy.

Nazwę pliku trzeba zmienić na wrapper_5.17_windows_intelx86.exe i/lub wrapper_5.19_windows_intelx86.exe <ewentualnie inny numerek zależnie od wpisów w app_info

[Thot]

Nowy wrapper działa. Pokazuje procentowy pasek postępu oraz czas do zakończenia przeliczania. Ale ...
1. Postęp uaktualniany jest skokowo (nie liniowo), co około minutę-póltorej (co w moim przypadku oznacza nawet kilka procent postępu),
2. Czas do zakończenia rośnie razem z czasem pracy (kolejne sekundy), by po uaktualnieniu postępu procentowego spaść do właściwej wartości, po czym znów przyrasta (kolejne sekundy). Czyli pokazuje rzeczywisty czas do zakończenia tylko w momentach uaktualniania.
3. Nie wiem jak z czasem przy wyjściu, ale chyba w porządku, bo nawet prawidłowo rozpoznał procenty jednostek przeliczanych na starym wrapperze.

P.S. Wrzuć już teraz nowe app_info na forum projektu. Niech się rozejdzie po ludziach. Będziesz mógł wcześniej odkręcić kranik ;-)

[TJM]

ad 1. - tego nie da się przeskoczyć, takie zachowanie wynika z konstrukcji głównej aplikacji. Updejtowanie jest jednak na tyle częste że z dużą dokładnością widzisz aktualny postęp i dodatkowo wskaźnik postępu zawsze pokazuje prawdę a nie jakieś zgadywanki jak to czasami bywa w różnych projektach.
Jedynie pod koniec przeliczania zdarzają się jakieś nieprawidłowości, czasami wskaźnik lubi przeskoczyć z 99.4-99.6 od razu na 100%, prawdopodobnie to rezultat zaokrąglania ale nawet nie mam zamiaru poprawiać takiej kosmetyki.

ad 2. - to standard w BOINCu, zawsze kiedy zatrzymają się procenty czas rośnie żeby potem zmaleć.

ad 3. - to normalne zachowanie, ale niestety czasu przeliczania po starym wrapperze nie da się rozpoznać, bo on tego w ogóle nie zapisywał  :)

app_info jest od wczoraj na forum, dziś dam cynk w newsach ponieważ wkrótce i tak stary app_info będzie bezużyteczny - to po prostu konieczność, muszę prędzej czy później porzucić starą wersję aplikacji która zawiera zbyt dużo plików i niepotrzebnie obciąża serwer ich ściąganiem.


Na szybkich procach wskaźnik przeskakuje od razu po parę procent, na wolnych bywa że nawet co 0.01 - po stronie aplikacji głównej jest uaktualniany chyba co 5 minut.


EDIT: jest pewien bug z zapisywaniem czasu procesora do checkpointa, nie mogę na razie tego rozgryźć - przy częstych restartach (normalnie raczej tego się nie robi ale przy testach zamykałem i otwierałem managera po kilka razy na minutę) czas potrafi sie czasami wyzerować jak dawniej, lub częściej - potrafi się cofnąć np. o połowę do tyłu. Jak to możliwe jeszcze nie wydedukowałem  :D

[Thot]

Ad1, ad2 - jeżeli znasz te objawy to wszystko w porządku.

Co do checkpointów to nie znam się na tym, ale tak z obserwacji (głównie SETI, bo tam mam największy staż) to po wznowieniu przeliczania postęp cofa się trochę, myśli przez jakiś czas, by potem przeskoczyć do właściwej wartości. Może jeżeli zrobisz coś (np. zamkniesz managera) w tym okresie "myślenia" to gubi zapisany czas checkpointa.

[TJM]

W tym przypadku zarówno wrapper jak i sama aplikacja przy prawidłowym zamknięciu zapisują aktualne informacje do pliku, nic nie ginie. W przypadku samej aplikacji działa to zawsze dobrze, w przypadku wrappera niestety czasami coś się kaszani i jako rezultat ładowany jest zły czas.