Hej,
po pierwsze, próbki w Rosetta są wysyłane z żądaniem liczenia przez pewien czas (obecnie standardowo to są chyba trzy godziny; można sobie to zmienić by np. mniej im obciążać serwer, ja mam ustawione 6 godzin). Jest to robione tak, że WU przelicza się i szuka kolejnych rozwiązań (decoys); kiedy scheduler uznaje, że nie uda się obliczyć kolejnej próbki przed ustawionym terminem, kończy WU i wysyła rozwiązanie. Inne dwa powody to AFAIR przeliczenie 99 rozwiązań albo błąd.
Dla sprawdzenia co się dzieje, przeczytaj komunikat stderr w opisie próbki (możesz podrzucić tu link, jeśli chcesz). Rozwiązań problemów technicznych najlepiej szukać na forum Rosetty (ja sam już nie monitoruję swojego przeliczania, robi to jeden stary komputer bez BAM setki kilometrów ode mnie).
Możesz mieć problem z jakimś konkretnym typem zadań, które może być bardziej pamięciożerne. Jakiś czas temu Rosetta podniosła oficjalne wymagania do 1GB RAM na jedno zadanie. Jeśli się tu nic nie zmieniło, zadania mają dość różne wymagania pamięciowe - serwer Rosetty powinien rozsyłać je opierając się na informacji o maszynie, ale w przypadku R@h nie wszystko jest przewidywalne (sam projekt jest w pewnym sensie wieczną betą, bo służy w pierwszym rzędzie testowaniu nowych protokołów, algorytmów i celów).
Może być i tak, że dany typ jest problemogenny. Inna sprawa to częste restartowaniu próbek - jeśli się nic nie zmieniło, to o ile pamiętam trzykrotne zrestartowanie próbki bez postępu w jej robieniu spowoduje jej automatyczny abort (rezygnację z niej i odesłanie). Teoretycznie mógłby być też problem z chłodzeniem albo interferencją z jakimś programem (np. mocno pamięciożernym).
Ale to takie moje gdybanie. :) Konkretne linki mogłyby pomóc - wraz ze zgłoszeniem w wątku z problemami technicznymi Rosetty.
po pierwsze, próbki w Rosetta są wysyłane z żądaniem liczenia przez pewien czas (obecnie standardowo to są chyba trzy godziny; można sobie to zmienić by np. mniej im obciążać serwer, ja mam ustawione 6 godzin). Jest to robione tak, że WU przelicza się i szuka kolejnych rozwiązań (decoys); kiedy scheduler uznaje, że nie uda się obliczyć kolejnej próbki przed ustawionym terminem, kończy WU i wysyła rozwiązanie. Inne dwa powody to AFAIR przeliczenie 99 rozwiązań albo błąd.
Dla sprawdzenia co się dzieje, przeczytaj komunikat stderr w opisie próbki (możesz podrzucić tu link, jeśli chcesz). Rozwiązań problemów technicznych najlepiej szukać na forum Rosetty (ja sam już nie monitoruję swojego przeliczania, robi to jeden stary komputer bez BAM setki kilometrów ode mnie).
Możesz mieć problem z jakimś konkretnym typem zadań, które może być bardziej pamięciożerne. Jakiś czas temu Rosetta podniosła oficjalne wymagania do 1GB RAM na jedno zadanie. Jeśli się tu nic nie zmieniło, zadania mają dość różne wymagania pamięciowe - serwer Rosetty powinien rozsyłać je opierając się na informacji o maszynie, ale w przypadku R@h nie wszystko jest przewidywalne (sam projekt jest w pewnym sensie wieczną betą, bo służy w pierwszym rzędzie testowaniu nowych protokołów, algorytmów i celów).
Może być i tak, że dany typ jest problemogenny. Inna sprawa to częste restartowaniu próbek - jeśli się nic nie zmieniło, to o ile pamiętam trzykrotne zrestartowanie próbki bez postępu w jej robieniu spowoduje jej automatyczny abort (rezygnację z niej i odesłanie). Teoretycznie mógłby być też problem z chłodzeniem albo interferencją z jakimś programem (np. mocno pamięciożernym).
Ale to takie moje gdybanie. :) Konkretne linki mogłyby pomóc - wraz ze zgłoszeniem w wątku z problemami technicznymi Rosetty.