AP20 i inne aplikacje w BOINC

[Jarek Wróblewski]

No dobra, kształtuje mi się takie wyobrażenie.

Każda przewidywalna aplikacja ma, powiedzmy, 3 argumenty liczbowe określające zakres, np.:

./ap20 s KMIN KMAX

Aplikacja produkuje plik z rozwiązaniami. Wielkość WU oraz pliku można praktycznie dowolnie regulować w miarę potrzeby. Ten plik jest dowodem przeprowadzenia obliczeń.

Być może w jednym momencie dobrze byłoby mieć jednocześnie kilka aplikacji. Wtedy można mieć jednocześnie kilka programów, a podmiana programu na inny byłaby mniej bolesna - bo stać by nas było na wsadzenie takiej aplikacji do kwarantanny.

Aplikacje muszą jakoś rozpoznawać, czy dany WU jest ich - ja nie wiem jakie są tu opcje.

Licząc w wąskim gronie można mieć chyba dość duże WU.

Jak rozumiem, TJM, potrzebowałbyś mieć konkretny działający program, żeby zacząć go obudowywać. Trzeba też pewnie ustalić pewne standardy co do nazw plików i aplikacji. Czy to jest łatwo zmienialne?

AP20 jest tu dość dobrym modelowym przykładem. Aplikacja ma dostać 3 parametry jak opisane wyżej, produkuje plik SOL-AP15.TXT i ten plik należy odesłać do weryfikacji.

Jej bliźniaczka, AP21 działa w sposób analogiczny, znaczenie parametrów jest takie samo, plik wynikowy nazywa się tak samo. To oczywiście można łatwo zmieniać.

Wyobraźmy sobie, że w przyszłości dokładamy aplikację TUP19, którą wywołuje się identycznie:
./tup19 s KMIN KMAX
i która też produkuje plik wynikowy, który należy odesłać do serwera.

W zasadzie chyba każdą przyszłą aplikację można wsadzić w ten schemat.

Czy to jest duży problem, zaplanować tak, aby było miejsce dla 3-5 różnych aplikacji jednocześnie?

To chyba z grubsza opis standardów, w które powinno się dać wsadzić każdy program.

[TJM]

Aplikacja BOINC niekoniecznie musi sprowadzać się do jednego pliku wykonywalnego, zwłaszcza jeśli odpala się ją przez wrapper (dlatego ja preferuję rozwiązanie wrapper + pliki wykonywalne aplikacji, zamiast wbudowywać BOINC API).
W skład aplikacji może wchodzić kilka plików wykonywalnych, a wybranie odpowiedniego może odbywać się na poziomie konkretnego zadania poprzez logiczne nazwy plików (obsługiwane od wersji 5.8 managera w górę).
Przynajmniej teoretycznie, bo w praktyce wymaga to wejścia w niezbadane tereny,  odpowiednie procedury w BOINC API są, ale ostatnio np. znalazły się poważne niedoróbki w obsłudze wrappera i to w znacznie częściej używanych funkcjach (ale też związanych z logicznymi nazwami). Trzeba byłoby sprawdzić, jeśli działa to poprawnie, to próba uruchomienia obliczeń których aplikacja w danym kliencie nie obsłuży (ze względu na brak odpowiedniego pliku wykonywalnego) zakończy się po prostu błędem ERR_RESULT_START i zadanie zostanie zaraportowane do serwera jako błąd.

[Pigu]

Zalety: Punkty BOINC za liczenie AP

zaczynamy mówić wspólnym językiem - masz na myśli punkty enigmy? :P

[TJM]

Tak, chyba żeby odpalić oddzielny projekt, ale jakoś słabo to widzę - pewnie na taki zamknięty projekt krzywo patrzyłyby inne teamy, podejrzewając nas zaraz o jakieś przekręty na punktach.

Znacznie bardziej elegancko byłoby przemycić dodatkowe aplikacje ukrywając je pod nazwami typu enigma_test_prealpha w E@H - w takim wypadku ograniczoną liczbę 'testerów' łatwo wytłumaczyć %-)

Wykorzystując nieużywaną już, pierwszą aplikację testowałem możliwości dodania kolejnej, żeby ocenić możliwość powstania ewentualnych problemów typowych dla projektów z wieloma aplikacjami. Główny problem jaki należałoby rozwiązać, to zarządzanie kolejką feedera, czego w BOINCu standardowo chyba nie ma. Bez tego możliwe jest wiele nieciekawych scenariuszy, np dwa najbardziej ekstremalne:
1) Zadania dla APxx zapychają kolejkę, bo feeder wciąga ich zbyt dużo, a zbyt mało pobierane jest do klientów, brak zadań Enigmy w kolejce.
2) Feeder zasysa zadania AP za wolno, przez co liczącym AP ciągle brakuje zadań.

Najłatwiejszy sposób ominięcia problemu, to monitorowanie ilości zadań AP w kolejce gotowych do wysłania i generowanie nowych kiedy ilość spada poniżej założonego poziomu. Jednak tu pojawia się kolejny problem, ponieważ wygenerowanie zadania nie oznacza, że trafi ono zaraz do kolejki feedera, musi przeleżeć pierw w kolejce 'results ready to send', z której zadania wysyłane są w kolejności utworzenia.
Tą kolejkę z kolei da się ominąć ustawiając dla zadania tryb 'high priority'. Jednak tu pojawia się kolejny problem: takie zadania z kolei są wysyłane tylko do kompów, które zwracają zadania dość szybko - serwer sprawdza RAC hosta (musi być 101+) i avg_turnaround (musi być poniżej 2 dni). Ktoś kto chciałby liczyć samo AP miałby więc problem z wystartowaniem (i większy, gdyby nie był w stanie utrzymać takiego RACa); jednak na szczęście bez większych komplikacji i konsekwencji da się wyedytować RAC użytkownika w bazie - ewentualnie sam wróci do takiego jaki powinien być.
Możliwe, że w najbliższym czasie dodam jakąś aplikację do testów, żeby zobaczyć jak to by wyglądało - na razie nie mam zbyt wiele czasu i jeszcze się przeziębiłem, wiec nie chce mi się nic robić  :( 

[Machloj]

kuruj się kuruj, a potem działaj :) bo punkty za AP baaardzo by mnie zmobilizowały XD

[Pigu]

nie mam nic przeciwko konieczności rozpędzenia racu na zadaniach eni :attack:

[TJM]

Niestety nie jest to takie łatwe. Jeszcze parę wersji serwera wcześniej spokojnie dało się wysyłać zadania do 'lewych' aplikacji które nie miały żadnej platformy lub wpisaną jakąś platformę z kosmosu.
Z obecną wersją serwera niestety taki numer nie przechodzi, w momencie kiedy znika ostatnia dopisana platforma serwer zaczyna ignorować takie zadania, co ciekawe zajmują one nadal miejsce w kolejce Results ready to send, ale są po prostu totalnie olewane. Więc raczej nie tędy droga.
Zastanawia mnie tylko czy jest to bug, czy też był to bug który został naprawiony. W sumie przecież aplikacja bez przypisanej platformy (tzn z dostępną jedynie 'anonimową' platformą poprzez app_info) to nie jest nic nadzwyczajnego.
Poczekam na następny stable release serwera i zobaczę czy coś się zmieni, wiem że aktualnie developerzy pracują nad anonymous platformami dla kart graficznych, więc może znów coś się zmieni w kwestii obsługi aplikacji.