Nadzorca

[TP]

Witam!

Mam pewien pomysł, który wydaje się łatwy do zrealizowania dla kogoś kto zna się na.... pisaniu programów....  :shame:

Pomysł może pozwolić ominąć niedoskonałości Boinc Menadżera w zakresie rozdzielania zasobów pomiędzy MW a CC.  Jeśli ktoś chce nabić dużą liczbę punktów to liczy w MW, ale projekt ten jest mniej stabilny jeśli chodzi o wysyłanie WU niż CC. W obecnej wersji BM jeśli mamy MW i CC aktywne, to de facto szanse działania ma tylko CC, gdyż wygryza próbki MW z różnych względów. Jak sytuacja z serwerami tych projektów wygląda - wszyscy wiemy cały czas są przestoje w efekcie czego grafika stygnie... ale przeważnie jest tak że chociaż jedne z nich działa...

Koncepcja jest taka: Nakazać BOINC menadżerowi liczenie próbek CC tylko wtedy gdy nie ma aktywnych próbek MW.

Jak to zrobić nie ingerując w kod BM?  |-?

Wymyśliłem coś takiego:

Założenia:

BOINC podpięty do MW i CC, ustawiony na pobieranie danych w obu projektach. CC domyślnie wstrzymany a MW zawsze jako aktywny.

Program nadzorca -> opis działania:

Sprawdzaj co 10s użycie GPU

Jeśli użycie GPU < 2% wznów przetwarzanie CC poprzez uruchomienie CCrun.bat, po upływie 5 minut wstrzymaj przetwarzanie CC poprzez uruchomienie CCstop.bat

Co 10 minut uruchamiaj MWupdate.bat i CCupdate.bat

Program więc opiera się na użyciu linii komend menadżera BOINC –legalne i bezpieczne  :parrrty:
Treść plików bat:
CCrun.bat
c:
cd "c:\Program Files\Boinc"
"c:\Program Files\Boinc\boinccmd.exe" --project http://boinc.thesonntags.com/collatz/ resume

CCstop.bat
c:
cd "c:\Program Files\Boinc"
"c:\Program Files\Boinc\boinccmd.exe" --project http://boinc.thesonntags.com/collatz/ suspend

MWupdate.bat
c:
cd "c:\Program Files\Boinc"
"c:\Program Files\Boinc\boinccmd.exe" --project http://milkyway.cs.rpi.edu/milkyway/ update

CCupdate.bat
c:
cd "c:\Program Files\Boinc"
"c:\Program Files\Boinc\boinccmd.exe" --project http://boinc.thesonntags.com/collatz/ update

Dlaczego przez 5 minut pozwolić liczyć CC? Ano tak sobie wymyśliłem.

Dlaczego sprawdzać aktywność GPU co 10s? w/w.

Jeśli program zadziałał by tak jak założyłem, grafika była by bez większych niż 10s przestojów wykorzystywana do liczenia. Programu nie musielibyśmy udostępniać drużynom zagranicznych, gdyż nie ingeruje w kod boinc – tylko wykorzystuje możliwości linii komend.... Myślę, że dzięki takiemu rozwiązaniu RAC polski o prę procent mógłby wzrosnąć...

Pytanie tylko – czy ktoś jest w stanie napisać taki program... ja programistą nie jestem... ale pomysł mam.

:respect:

[X X X]

Tomasz, dlaczego zrobiłeś włam do mojego kompa?  :wth:

Nie do końca wiem jak się do tego odnieść - konkurujemy czy współpracujemy?
Jak konkurujemy to dlaczego robić to wspólnie?
Jak współpracujemy, to może pomyślmy o fuzji i stworzeniu jednego teamu narodowego?

A co do meritum:
1. Zagadnienie zidentyfikowałeś ideowo słusznie, ale jest ono sporo bardziej skomplikowane niż napisałeś, bowiem... projekty i BM mają swoje fochy. Proste przełączanie jest stratne, bo grafy startują zawsze od początku a zadanie Colla trwa 10-12 min x N. Przełączanie bezstratne robi się bardzo skomplikowane i w dużym stopniu zależne od używanych graf i kompozycji coproc i n.

2. Mam napisane takie coś od dwóch tygodni i nazywa się właśnie Nadzorca. :)
Moja wersja nie ma żadnych cech uniwersalnych, jest ściśle związana z konfiguracją moich kompów, z moimi grafami i ich konfiguracją. Przy każdej zmianie BM czy algorytmów wymaga przeprowadzenia testów i tunningu, bo - przykładowo - wstrzymanie tylko jednego zadania blokuje ściąganie wszystkich następnych, itd. Czym dalej w las, tym więcej drzew i boincowych fochów...

Każdy może napisać sobie prosty skrypt na bazie jawnych komend boinccmd. Najprostszą wersję można zorganizować na bazie skryptu typu bat. Użyj algorytmu, który przedstawiłeś i będzie ok.

[TP]

Konkurujemy współpracując  XD To chyba oczywista oczywistość!  XD

Innymi słowy, pytanie o to co jest ważniejsze: pozycja POLSKI jako kraju w rankingu czy pozycja B@P lub TPT w rankingu...

Czyli robić wspólnie dla pozycji POLSKI... lub osobno dla pozycji drużyn... Ja współpracę technologiczną z B@P zadeklarowałem zanim dołączyłeś do B@P...

A co do meritum:

Ad 2.

Pochwal się tym co masz   ;)

Zapodaj treść na forum albo na PW

Chyba że to tajne...  %)

[X X X]

Nie jest tajne, ale raczej niezrozumiałe, bowiem napisane w czymś dla współczesnych anachronicznym, czyli w Pascalu.
XD
Poza tym, nie wiem czy jesteś świadom, ale w B@P osoby liczące na grafach są "na cenzurowanym". Niektórzy uważają wręcz, że liczenie na GPU jest jakieś... nieetyczne, bo nie każdego stać na grafę i takie tam pierdoły. Tylko liczenie na CPU jest ideowo słuszne! Nawet zaproponowałem założenie oddzielnego teamu osób liczących na grafach, gdzie nikt nikogo nie będzie deprecjonował ani nie dzielił projektów na lepsze i gorsze.

Może zatem nie rozwijajmy tego wątku, bo zaraz forumowa większość nas zadziobie.
XD

[Troll81]

nie wiem czy jesteś świadom, ale w B@P osoby liczące na grafach są "na cenzurowanym". Niektórzy uważają wręcz, że liczenie na GPU jest jakieś... nieetyczne, bo nie każdego stać na grafę i takie tam pierdoły

szkalujesz własny zespół...... przeginasz stary.... to się robi niesmaczne.....

Ty chyba naprawdę chcesz doprowadzić do jakiś sztucznych podziałów..... nie ogarniam cię. NIkt nigdzie nie pisał że liczenie na grafach jest nieetyczne ani niczego takiego nie sugerował.

co się zaś tyczy współpracy i konkurencji międzydrużynowej... chętnie podam rękę kolegom z TPT :D może i iedyś dokonamy fuzji :D by dokopać czech national team :D

[X X X]

to się robi niesmaczne.....

Twoje działanie jest już dla mnie od dawna nie tylko niesmaczne, ale wręcz wredne.

[Troll81]

sądzę że twoje wypowiedzi wystarczająco świadczą o tobie....

dodatkowo przenosisz prywatną kłótnię do wątku który został stworzony z myślą o czym innym niż czytanie twoich żalów i narzekań.

Wracając do tematu nadzorcy. Liczenie na GPU jest na tyle młodą dziedziną w BOINC że dopiero od niedawna manager obsługuje karty ATI a projekty GPU można policzyć na palcach jednej ręki. Myślę że takie wstrzymywanie i uruchamianie bardzo zależałoby od konfiguracji sprzętu. Ale nie jest to niewykonalne. Na naszym forum bardziej doświadczonym programistą jest TJM i Sesef i to chyba ich warto zapytać na PW.

[Szopler]

Panowie! Spokojnie... Tworzyć teamu dla liczących na GPU nie ma sensu bo zaraz by się rozpadł - wojna czerwonych (ATI) z zielonymi (NVidia) ;). To normalne, że każdy ma swoje zdanie, ale ciągłe sprzeczki niczego nie załatwią. Jak tak dalej pójdzie to będzie trzeba napisać sztywny regulamin np. PM i oczywiście każdy podpunkt tego regulaminu przegłosować w ankiecie... a potem się do niego zastosować :book:

[3Rni]

sorki za OT

czy są jeszcze jakies watki na forum gdzie nie toczy sie batalia 7NBI_Zarecki Robert vs Troll81???

gdzie nie wejdę poczytać krew się leje  :attack: -- plz mam ochote cos innego poczytać tu na forum

i do tematu:

TP wierć dalej temat sam jestem ciekaw rozwiązań , bo mi często stoi   :P  -- milka ofcoz  XD

[Tomasz R. Gwiazda]

ja chetnie skozystam z efektow pracy :P

[TJM]

Nie łatwiej zamiast monitorować pracę GPU po prostu sprawdzać, ile manager ma próbek MW w zapasie, w stanie nienapoczętym i odblokowywać collatza jeśli liczba spadnie do zera ? To max paręnaście-parędziesiąt (zależnie od 'idiotoodporności' kodu) linijek kodu np. w autoicie, a powinno być w 100% niezawodne i niezależne od wersji managera.
Trzeba by tylko znaleźć kryterium, na podstawie którego skrypt blokowałby pobieranie collatza w razie pojawienia się zadań MW.

Jeszcze lepiej byłoby napisać własny program oparty o guirpc (taki dodatkowy manager), dawałby +100 do możliwości kontroli (pewnie nawet możliwe akcje typu "jedna grafa liczy collatz dwie milkyway"), ale stopień trudności o wiele wyższy.

[X X X]

Z tym równoczesnym, to kicha, bo w aktualnym mgr, jak masz włączonego Colla, to MW za cholerę nie ruszy, więc jedyną metodą jest wyłączanie Colla. I to działa. Jedyny problem jest taki, że MW pojawia się i znika, a Collo leci 12m, a będzie 18m. I jak masz parę wątków, to skubańce nie idą równo, tylko np. jeden kończy, drugi jest w połowie, a trzeci zaczyna. Ale i na to jest metoda, bo jak Milki najdzie, to należy wyłączyć wszystkie 356 oczekujących zadań Colla, co poprzez boinccmd trwa jakieś 30s, ale stopniowo Collo się kończy i wu z MW ruszają. Na koniec trzeba jeszcze wyłączyć Colla na poziomie projektu i włączyć poszczególne wu, aby podjęły pracę w następnej fazie. To wszystko trybi.

Podstawowy problem, który sprawia, że kod ma dużo dużo więcej linijek niż te kilkanaście, polega na tym, że nie znam metody odczytu bezpośredniego o stanie i liczebności wu, zatem pozyskuję informacje przez przejęcie i rozkodowanie strumienia tekstowego generowanego przez boinccmd.

[TJM]

To wszystko o czym mówisz ma (częściowy) sens tylko jeśli korzystasz z boinccmd. Korzystając z guirpc można zrobić automatycznie dokładnie to samo, co da się zrobić ręcznie w mangerze, czyli wszystko.
Nie wiem też z jakiej paki wstrzymanie iluśtam zadań ma trwać 30s ? W ogóle nie można wstrzymać na raz całego projektu ?

[X X X]

Można wstrzymać cały projekt. Tylko to się nie opłaca - lecą dwa Colle, jeden ma 10min, a drugi 11min. Wstrzymujesz i jest ok, ale jak wznawiasz, to Colle startują od 0% i masz 20 min pracy gpu (900pkt) w cholerę wywalone.

Wstrzymywanie pojedynczych zadań odbywa się w tempie 10/s, więc >300 trwa pół minuty. Pewnie odpowiada za to częstotliwość kontaktu z klientem.
To daj linka do opisu tego guirpc, to będę usprawniać. ;)

[TJM]

Nie wiem czy jest jakaś dokumentacja guirpc, pewnie musi gdzieś być bo przecież powstają alternatywne managery (np. boincview).
Na pewno dużo da się wyczytać ze źródeł managera (nie mylić z core clientem).
Skoro zatrzymywanie zadań idzie tak wolno, to ja widzę pewne ciekawe rozwiązanie - regulowanie pobierania poprzez włączanie NNT dla projektu i wstrzymywanie/odblokowywanie zadań na bieżąco, kiedy są potrzebne. Ewentualnie pobranie raz na maksa, wstrzymanie większości i odblokowywanie np. 2 * liczba_gpu zadań naprzód. W ten sposób klient powinien być 'głodny' cały czas i często próbować pobierania z MW.
Co prawda kiedy wiszą zadania wstrzymane dla projektu, manager nie będzie pobierał nowych, ale to nie problem - po prostu dodatkowa kontrola w skrypcie - kiedy zostanie np. tylko 10 zadań, odblokować wszystkie i wyłączyć NNT - wtedy manager sam z powrotem zapełni bufor. Po zapełnieniu znów NNT i powrót do starego cyklu.

[X X X]

Sam widzisz jak ładnie namnaża się te kilkanaście wierszy kodu.  XD

0. A cóż to jest to NNT dla projektu? Może NMT = no more task?

1. Pobieranie MW nie jest problemem, bo może być włączone i popędzane cały czas i nie blokuje to w niczym Colla.

2. Jest pewien konflikt dwóch celów - z jednej strony, czym mniej zapasu Colla, tym zgrabniej i szybciej wszystko chodzi. A z drugiej strony, jak nie nałapiesz pełnego zapasu 360 wu Colla, to w suchy weekend leżysz. Dlatego bezapelacyjnie trzeba taszczyć te 360 wu. A na dodatek czasem to odświeżyć wywalając przeleżałe WU.

3. Czas robienia on/off na zadaniach Colla nie jest problemem, bo zadania Colla trwają kilkanaście minut a przełączenie tylko pół. Natomiast Milkę wystarczy nie załączać póki nie najdzie z pół bufora (u mnie 12 szt.).

4. Stałe włączanie i wyłączanie zadań wydaje się oczywistością i też na to wpadłem. Jest tylko jeden fundamentalny feler - jak jest wstrzymane choć 1 wu w danym projekcie, to nic więcej nie zostanie już pobrane, obojętnie czy masz 10 czy 300 w kolejce. Dlatego w ramach jednego cyklu MW-CO-MW trzeba parę razy robić on/off na poziomie zadań. I dodatkowo dopieszczać pobieranie, bo Collo też bywa kapryśny w podsyłaniu zadań - najpierw parę razy wysyła na CPU, gdzie ma limit do 120, a dopiero po kilku odpytaniach łaskawca zrobi zapytanie na GPU, gdzie ma limit 360. A biorąc pod uwagę, że ostatnio jeszcze wydłużyli minimalny czas między odpytaniami, to realne pobranie Colla >120 może nastąpić dopiero wtedy, kiedy leci druga para Colla, a MW jeszcze nie naszła lub została powstrzymana, gdyż zapas Colla zszedł poniżej założonego minimum. Z kolejnej strony nie można za długo czekać na Colla, bo może Godotem się okazać, więc trzeba sprytnie i dynamicznie parametryzować priorytety na oba dyszle, itd., itp.
No, ale nie święci garnki lepią. ;)

[TJM]

To wszystko tylko wydaje się skomplikowane, ale po ustaleniu podstawowej logiki co kiedy ma się dziać i dlaczego, skrypt byłby dość prosty do napisania.
Jako bonus jeszcze można byłoby dorzucić obsługę wielu komputerów, albo jednym skryptem, albo kilkoma łączącymi się przez sieć i informującymi wzajemnie, że np. właśnie w MW są dostępne zadania.
Teoretycznie możliwe byłoby też wykorzystanie do zabawy np. 3 HALowców, z których na raz tylko jeden by liczył, a dwa pozostałe siedziałyby cicho jako magazyny zadań, włączane w razie potrzeby. To już lekkie naginanie zasad, no ale cóż %)
Niepobieranie zadań przy wstrzymanym projekcie jest bardzo proste do usunięcia, ale niestety wymaga rekompilacji klienta - usunięcie w źródłach dosłownie kilkunastu liter.

[X X X]

Jasne, myślałem o tym. Brakuje tylko jednej rzeczy. I dobrze wiesz jakiej. Na początku ma H, a na końcu 10.
XD
A, i jeszcze jedno - wyłączanie poszczególnych graf ATI nie działa, co napisano w Readme. Na dodatek nie ma tak, że wprost nie działa, niby czasem działa, ale jednak nie działa. Nazwano to... Do not use it with an ATI aware BOINC client! It should be ignored in that case. But there may be some unwanted side effects. Pewnie można to jakoś próbować obejść, ale... patrz pierwsze zdanie.

[TJM]

Do działania na HALowcach nie potrzeba wyłączania graf. Każdy klient myśli że jest jedyny, więc wystarczy włączyć wszystkie, pozwolić im pobrać zadania, po czym nadmiarowe zablokować żeby liczył tylko jeden. Prawdopodobnie wiązać się to będzie z włączaniem kolejno i zatrzymywaniem kiedy się napełnią. Wtedy jeden może jechać normalnie, a pozostałe będą wisieć napełnione jako zapas.
Skrypt musi kontrolować tylko deadline, ewentualnie co jakiś czas przełączać aktualną instancję klienta na 'zapas' po upewnieniu się, czy jest napełniony do oporu.
Wady: każdy klient widziany jest jako osobny host, więc o wbiciu do 'top hosts' można zapomnieć.

[X X X]

Proponuję większość tego wątku przenieść do czarnej dziury, bo żeśmy się chyba za bardzo rozgadali.