Planowana przerwa

W związku z przerwą w dostawie prądu, dziś od godziny 7:30 do mniej więcej 15 serwer będzie offline.

Klient i serwer w wersji 0.5

Kolejne zmiany po stronie serwera i klienta. Zmiana sposobu pobierania i odsyłania wyników, trochę obsługi błędów i zabezpieczeń po stronie klienta i ogólnie lekkie poprawki, żeby źródło stało się nieco bardziej czytelne. Wznawianie przerwanych obliczeń działa teraz dużo lepiej, starsze wersje często potrafiły zgubić zadanie po przerwaniu w pobliżu końca obliczeń. Dodana obsługa enigmy M4 i drugiej wersji słowników.

Serwer - przepisane części odpowiedzialne za przydzielanie i weryfikację zadań, trochę pod kątem kompatybilności z przyszłym BOINCowym projektem (w trakcie budowy). Weryfikacja zadań krótsza o jeden stopień i sporo szybsza.
Dodana obsługa wielu słowników i Enigmy M4, a także wrapper do projektu M4 Stefana Kraha, używany, kiedy kończą się zadania.

Klient w wersji 0.4

Przez ostatnie dwa dni dłubałem trochę w oprogramowaniu projektu, głównie od strony serwerowej.
'Protokół' klient-serwer nieco się zmienił, w związku z czym serwer odrzuca połączenia od wszystkich wersji klienta poniżej 0.4. Ponadto w klientach poniżej 0.4 brakuje drugiej wersji enigmy, co trochę negatywnie odbija się na obliczeniach, zmieniając proporcje między liczbą restartów dla obu sposobów szukania pierwszych par steckera.

'Widoczne' zmiany po stronie serwera to głównie kosmetyka - przeglądarka wyników pokazuje teraz średnią liczbę restartów dla każdego tekstu, dzięki czemu można mniej więcej ocenić postępy.
Zostało udowodnione, że dla opornych tekstów konieczna do złamania liczba restartów może sięgać 10,000 (słownie: dziesięć tysięcy %-)). Poza tym sama przeglądarka działa szybciej.

Zmiany po stronie klienta: nadal ten sam skrypt, napisany 'na kolanie' z paroma poprawkami + druga aplikacja. Źródła dostępne na stronie razem ze źródłami obu aplikacji (oryginalnym i przerobionym). Skrypt można skompilować do .exe autoitem, obie aplikacje jakimś kompilatorem C/C++, dołączone są projekty DevCPP.

Weekendowe testy

W ostatni weekend wpadłem na pomysł przetestowania całej 'sieci', żeby zobaczyć, czy w ogóle oprogramowanie jest sprawne i da radę coś złamać. Wypuściłem 4 dodatkowe serie work unitów: test2_pgnax1-4. Pierwsze trzy to podzielona mniej więcej na trzy części wiadomość, czwarty to całość.
Cała wiadomość została złamana za pierwszym podejściem przez komp Kanibala %-) http://kfd.no-ip.org/enigma/results.php?p=test2_pgnax4

ringi nie są jeszcze w prawidłowym położeniu, ale to da się dopracować ręcznie.

Ten sam komp złamał także wcześniejszą testową wiadomość, wszystkie ustawienia prawidłowe:

http://kfd.no-ip.org/enigma/results.php?p=test1_pbnxa

niestety wiadomości podzielone na części jeszcze nie zostały rozpracowane, wymagają prawdopodobnie dużo większej liczby restartów, co zajmie trochę czasu przy aktualnej mocy obliczeniowej.

Porównanie szybkości procesorów

Tak to wygląda od strony serwera projektu, według danych zwracanych przez oprogramowanie w wersji 0.3+. Prędkość podana względem Celerona Tualatina 1,4 podkręconego do 1.6 GHz:

Core2 Duo 1.86, jeden rdzeń - 3.11 *
Celeron D 2.13 @ 3.65 - 2.18
Celeron D 2.13 @ 3.5 - 2.09
Celeron D 2.8 - 1.64
Tualatin 1300 - 0.76
Athlon 1400 - 0.75
Pentium III 966 - 0.52
Celeron 666 - 0.38
Pentium III (Katmai) 550 - 0.35

* - dość ciekawa sytuacja, bo w benchmarku (tym dołączonym do klienta) taki Core2 wypada trochę poniżej Celerona D @ 3.5GHz, ale w 'prawdziwych' obliczeniach zostawia go daleko w tyle... Przy użyciu obu rdzeni różnica prędkości wychodzi 3-krotna na korzyść Core2.

Upgrade do wersji 0.3

Wprowadziłem dziś pewne zmiany po stronie serwera, np. ograniczenie czasu 'życia' wysłanego WU do 4 dni, żeby uniknąć sytuacji, kiedy serwer przechowywałby w nieskończoność dane o zadaniach, które dawno przepadły.
Oprócz tego, od wersji 0.3 serwer przechowuje szacowaną prędkość każdego zdalnego komputera (klient razem z wynikami odsyła czas który był potrzebny na obliczenia), co pozwoli w przyszłości przydzielać zadania o długości zależnej od szybkości zdalnego kompa, w ten sposób wolniejsze maszyny nie dostaną zadań które trwałyby na nich zbyt długo, a szybsze nie będą 'floodować' serwera odsyłaniem wyników co 30s.

Nowa wersja serwera będzie jeszcze przez kilka dni kompatybilna z klientami w wersji 0.2, w tym czasie zalecany jest upgrade klienta do wersji 0.3.
Konfiguracja taka sama jak w poprzednich wersjach - wystarczy podać nazwę użytkownika i opcjonalnie czas przerwy między zadaniami oraz ewentualnie ustawić start z oknem zminimalizowanym.

Upgrade - powinno wystarczyć zatrzymanie klienta 0.2 i zastąpienie client.exe wersją 0.3

Po pierwszym uruchomieniu w pliku .ini pojawia się nowa linijka z wpisem hostid - jest to wygenerowany losowo identyfikator klienta. ID jest używany na serwerze w procesie przydzielania zadań oraz weryfikacji odesłanych.

Info dla posiadaczy maszyn z wieloma rdzeniami/procesorami: bez problemu da się wykorzystać wszystkie dostępne rdzenie/procesory, wystarczy stworzyć odpowiednią liczbę kopii katalogów klienta i kolejno je uruchomić, prawidłowym podziałem zadań między procesorami powinien zająć się system (testowałem na Core2 Duo, działa zgodnie z oczekiwaniami).

Poniedziałkowy tłok ;)

Wczorajsza ponadprzeciętna moc obliczeniowa 'projektu' zakończyła serię krótkich zadań z serii '140'. Aktualnie priorytet mają zadania z wiadomością #138 - obydwie prawdopodobnie zaszyfrowane zostały przy użyciu tych samych ustawień, tak więc złamanie jednej daje też dostęp do drugiej.
Większość zadań serii '138' ma długość 26, czas przetwarzania może sięgać ponad 30 minut na przeciętnym kompie. Okazjonalnie serwer będzie wysyłał też inne zadania, ponieważ powoli przekopuję się przez błędne wyniki i prawdopodobnie dla części work unitów cofnę trochę licznik restartów, uwzględniając to, że niektóre zgłaszane rezultaty były niepoprawne.

EDIT: w tytule powinno być 'wtorkowy', przez drzemki w środku dnia spowodowane przeziębieniem pomyliły mi się dni tygodnia %-)