Zauważyłem we wiadomościach menadżera,że dwa projekty potrafią przełączać się pomiędzy sobą w bardzo krótkim spektrum czasowym...
Dla przykładu. Projekty SIMAP i Poem od godz. 18.00 do 20.00 przełączyły się 44 razy. Odstępy czasowe są bardzo różne; od kilku sekund do kilkunastu minut. Terminy zaraportowania obu są takie same 17 stycznia. Czas liczenia dla SIMAP 6h, a dla POEM 18h, gdzie SIMAP (jedna próbka) przeliczył 28%, a POEM (dwie próbki, ten sam DL) przeliczył 20%.
Sytuacja zdarza się sporadycznie, nie mniej już wcześniej się zdarzyła dla innych projektów.
Z czym wiąże się takie zachowanie BAM?
BAM czy BOINC Manager?
BOINC Menager
Zobacz, czy przy przeliczanej próbce w menedżerze pojawia "wysoki priorytet" obok "przetwarzany". To raz.
Dwa. Zaawansowane -> Preferencje lokalne -> Użycie procesora -> przełączaj się pomiędzy aplikacjami projektów co X minut
Pierwsze oznacza, że masz za dużo próbek w buforze i menedżer uważa, że z czymś nie zdąży przed deadline'ami. Drugie ustawienie wedle uznania, u mnie komp chodzi 24h/dobę, więc ustawiam tak, aby próbki zdążyły się zazwyczaj przeliczyć bez przerywania = 12h. Ten "wysoki priorytet" pomija to ustawienie, więc podejrzewam, że to to tyle ci miesza. Zawieś trochę próbek na jakiś czas, niech przeliczy część, potem odwieś. Na przyszłość skróć zapas próbek (Zaawansowane -> Preferencje lokalne -> Użycie sieci -> dodatkowy zapas danych na X dni)
CytatZobacz, czy przy przeliczanej próbce w menedżerze pojawia "wysoki priorytet" obok "przetwarzany".
CytatPierwsze oznacza, że masz za dużo próbek w buforze i menedżer uważa, że z czymś nie zdąży przed deadline'ami.
CytatTen "wysoki priorytet" pomija to ustawienie, więc podejrzewam, że to to tyle ci miesza. Zawieś trochę próbek na jakiś czas, niech przeliczy część, potem odwieś.
Zastanawiałem się na nad terminem "wysoki priorytet" i zakładałem, że ma on coś wspólnego z ilością danych w buforze. Faktycznie pojawia się ta informacja. Po zawieszeniu większości próbek, których DL są stosunkowo odległe, w statusie zadania pozostał tylko termin "przetwarzane". Czyste potwierdzenie Twoich słów.
Nie mniej sądzę, że BM nie jest zbyt dokładny. Łączny,szacunkowy czas przeliczenia próbek, które nie zostały wstrzymane (w tym przypadku wyłącznie SIMAP, ze względu na projekt m-ca) wynosi 110h, a ich DL to 20.01, więc zostaną przeliczone dużo wcześnie niż wynosi ich DL. Mimo, to po odwieszeniu jakiejkolwiek innej próbki, której czas przeliczenia jest bardzo krótki, powoduje powrót statusu "przetwarzany, wysoki priorytet"...
CytatDwa. Zaawansowane -> Preferencje lokalne -> Użycie procesora -> przełączaj się pomiędzy aplikacjami projektów co X minut
CytatDrugie ustawienie wedle uznania, u mnie komp chodzi 24h/dobę, więc ustawiam tak, aby próbki zdążyły się zazwyczaj przeliczyć bez przerywania = 12h.
Ustawiłem standardowe 60minut. Host pracuje również 24h/dobę, jednak nie studiowałem jeszcze innych ustawień. Zakładam jednak, iż w przypadku liczenia jednego projektu (jw.), to ustawienie nie nie ma większego znaczenia...
CytatNa przyszłość skróć zapas próbek (Zaawansowane -> Preferencje lokalne -> Użycie sieci -> dodatkowy zapas danych na X dni)
I tak uczyniłem, zmiana z 7 na 4.
Też mi się nie podoba działanie tego mechanizmu, więc unikam takich sytuacji jak ognia.
Unikanie takich sytuacji wiąże się z częstym kontrolowaniem statusów zadań. Każde zakończenie przeliczania danej próbki w określonym projekcie powoduje zmniejszenie szacunkowego czasu przeliczania pozostałych próbek tegoż projektu.
Nie sądzę, aby można było by stosunkowo dokładnie określić tą różnicę ze względu na zbyt dużo liczbę zmiennych dotyczących zasobów, które w danej chwili ma do dyspozycji dane zadanie. Zakładam, że ważną rolę odgrywają również same próbki, a dokładniej ich "treść", którą aplikacja musi przeliczyć.
Zastanawiam się czy taka zmiana przedziałów czasowych potrzebnych do przeliczenia próbek danego projektu odnosi się również do zmian czasu liczenia próbek z innych projektów liczonych naprzemiennie...
Uniaknie takich sytuacji wiąże się z jednym, przejściem na model, jeden komp - jeden aktywnie liczony projekt.
W cyklu jaki uznasz za stosowne, rocznym, miesięcznym (projekt miesiąca), tygodniowym, jednodniowym.
Zdecydowanie wygodniejsze i praktyczniejsze.
Poza sytuacją w której nie kontrolujesz hosta lub masz czasowo ograniczoną kontrolę.
Ponieważ BM nie dorobił się prostego mechanizmu aktywowania drugiego uśpionego projektu.
Rozwiązanie - napisać prosty skrypt.
CytatUniaknie takich sytuacji wiąże się z jednym, przejściem na model, jeden komp - jeden aktywnie liczony projekt.... Zdecydowanie wygodniejsze i praktyczniejsze
To oczywiste. Natomiast istnieje dużo innych projektów, w których warto brać udział, więc idąc Twoim tropem trzeba by posiadać "stajnie" maszyn jak w archiwach danych cyfrowych :).
CytatPoza sytuacją w której nie kontrolujesz hosta lub masz czasowo ograniczoną kontrolę.
Takie rozwiązanie jest dobre raczej w sytuacji, w której właśnie nie kontrolujesz hosta lub masz czasowo ograniczoną kontrolę...
każdego projektu uruchom osobna maszyne wirtualną :D
Czytałeś dane mojej obecnej maszyny, więc uznam to za BOINCowy żart XD
Ja trzymam bufor zadań na 0.25 dnia i nie mam tego problemu, nawet jakbym liczył 5 projektów na raz. Chyba, że projekt ustawi deadline próbek na dzień lub mniej, wtedy jest problem, bo 'wysoki priorytet' się na tym włączy niezależnie od wszystkiego, ale wtedy to wina projektu.
BM dorobił już się mechanizmu 'projektu zapasowego', ale serwer projektu musi chyba to wspiera. Mi to działa w przypadku liczenia na GPU MW i jako zapas collatza. Ustawia się resource share na 0 dla tego projektu i już.
ciekawe :D muszę wypróbować :D
Przyjdzie czas i na takie kombinacje :).
Najważniejszym jest liczyć, a co za tym idzie, kontrolować ów operacje w rozsądnym stopniu...
Gdyż, rzekł bym, że liczenie nie jest po to, aby żyć, a życie po to jest, aby liczyć... ;)
Greats
Cytat: DeepCore w 14 Styczeń 2011, 13:04
Gdyż, rzekł bym, że liczenie nie jest po to, aby żyć, a życie po to jest, aby liczyć... ;)
:parrrty:
Zawsze i wszędzie i bynajmniej nie zawsze w ramach rozsądku ;) XD...