Dzisiaj pokażę Wam wynik pracy na potrzeby projektu, o którym wspominałem już wcześniej. Animacja trwa 3 minuty i renderowała się ok. 3 dni na podkręconym (3651 MHz) procesorze Core 2 Duo E8400. Dodam, że jak na standardy amatorskiej animacji to raczej krótko - trzeba było włożyć wiele wysiłku w to, aby trwało to tylko tyle. Ciągle z niektórych rzeczy nie jestem do końca zadowolony, ale zwyczajnie zabrakło czasu, żeby je ulepszyć. Pozostaje dodać, że licencja Creative Commons, którą objęta jest użyta muzyka, nakazuje mi poinformować, że jej autorem jest Matti Paalanen, a utwór nazywa się Hope for Rebirth.

Animację w średniej (dopiero po wciśnięciu przycisku HQ), jakości możecie zobaczyć tutaj:


Animację w dużej jakości (polecam) można pobrać z serwisu MegaUpload.
komentarze (5)

Już dość dawno temu opisałem, w jaki sposób przyspieszyłem start Debiana o ok. 7 sekund. W ramach ostatnich dni pojawiło się jądro 2.6.30, które wprowadza kolejne zmiany mające na celu przyspieszenie bootowania. Pomyślałem, że to dobra okazja do kompilacji.
Zanim przejdę dalej, powinienem opisać, jak mierzę czas startu - zwłaszcza, że zmieniło się to od poprzedniego wpisu. Czas bootowania mierzyłem stoperem. Pomiar rozpoczynałem w momencie wciskania enter w GRUB'ie, a kończyłem w momencie pojawienia się linijki zachęcającej do zalogowania (wyłączyłem kdm). Czasy, które podaję w dalszej części tego wpisu, to średnie z trzech pomiarów.
Korzystając z okazji postanowiłem pozbyć się initrd, który podobno wydłuża bootowanie o ok. 1-1,5 sekundy. Wiele dystrybucji Linuksa używa initrd przy rozruchu systemu. Dzięki temu, mogą skompilować uniwersalne jądro, które jednocześnie będzie zajmowało mało miejsca. Nas uniwersalność nie obchodzi - z założenia kompilujemy jądro tylko dla siebie. Aby rezygnacja z initrd nie skończyła się na Kernel Panic, musimy wkompilować w jądro parę rzeczy. Przede wszystkim będzie to obsługa naszego dysku twardego, używany na partycji linuksowej system plików, oraz obsługa dysków SCSI (o ile Linux rozpoznaje nasz dysk np. jako sda, a nie hda). U siebie musiałem ustawić takie opcje:

General Setup > Initial RAM filesystem and RAM disk support [N]
Device Drivers > SCSI device support > SCSI disk support [Y]
Device Drivers > Serial ATA and Parallel ATA drivers > ATA SFF support [Y]
Device Drivers > Serial ATA and Parallel ATA drivers > Intel ESB, ICH, PIIX3, PIIX4, PATA/SATA support [Y]
File Systems > Ext3 journalling file system support [Y]

Tradycyjnie na początku wykonałem pomiar kontrolny, żeby mieć odniesienie. Na moim poprzednim jądrze - 2.6.28.6 (również skompilowanym przeze mnie), czas startu wyniósł 20,76 sek. Natomiast świeżo skompilowane jądro 2.6.30 wystartowało w 18,07 sekund, czyli niemal o 3 sekundy szybciej. Zauważyłem jednak, że trzeba powtórzyć jedną z operacji z poprzedniego wpisu ( touch /etc/readahead/profile-once ). Po jej wykonaniu kolejny start trwał dłużej, bo readahead zbierał informacje. Kolejne starty systemu były już dużo szybsze, czas wyniósł 15,49 sekund. Widzimy, że ostatecznie udało się przyspieszyć bootowanie Debiana o ponad 5 sekund. Z pewnością większa to zasługa poprawek w jądrze, niż pozbycia się initrd.
komentarze (0)

Obiecałem, że wstawię wyniki ankiety nt. palenia papierosów, ale prawda jest taka, że nie udało nam się znaleźć jakichś zaskakujących, czy ciekawych powiązań. Zdecydowana większość reguł, które znaleźliśmy była banalna lub przynajmniej łatwa do domyślenia się samemu. Inna sprawa, że ankieta nigdy nie była i nie miała być miarodajna - od początku chodziło w niej o wypróbowanie technik eksploracji danych, a nie prawdziwe badanie. Na dodatek przy końcowej prezentacji okazało się, że prawdopodobnie coś mocno skopaliśmy, bo reguły powinny wyglądać inaczej. Z drugiej strony Knime (program, w którym wszystko robiliśmy) nie należy do skomplikowanych. Szukałem opcji i ustawień, aby reguły wyglądały tak, jak powinny, ale nie znalazłem. Chociaż rozsądek podpowiada, że to mało prawdopodobne, to jednak z naszej perspektywy wygląda to na winę programu. Ale mniejsza z tym - projekt mamy z głowy.
Mimo wszystko obiecałem przedstawić wyniki, więc napiszę chociaż jedną regułę, którą osobiście uznałem za najciekawszą:
Palaczami rzadko zostają osoby, które jeszcze nie zarabiają (lub zarabiają mało) i jednocześnie przeszkadza im dym tytoniowy. Zazwyczaj palą osoby neutralnie lub pozytywnie nastawione do dymu, mające jednocześnie większe zarobki lub pochodzące z większego miasta.
komentarze (0)

Na obecnym semestrze studiów mam przedmiot o nazwie Hurtownie i Eksploracja Danych. W ramach tego przedmiotu mam projekt, na który muszę wraz z kolegą przeprowadzić ankietę na temat palenia papierosów, a potem na podstawie zebranych danych wygenerować wiedzę. Generalnie chodzi o automatyczne znalezienie różnych ciekawych powiązań, które po zakończeniu projektu z pewnością opublikuję na tej stronie. Zapraszam do wzięcia udziału w ankiecie, nie jest ona długa - poświęcisz mniej, niż 5 minut, a wspomożesz studentów w potrzebie ;)

do ankiety

komentarze (0)

Zgodnie z tym, co pisałem wczoraj, postanowiłem zrobić w POV Ray jakiś filmik. Wiem, że nie jest to nic specjalnie pięknego, ani wymyślnego. Moim głównym celem była nauka precyzyjnego kształtowania krzywej, po której porusza się kamera, co będzie bardzo istotne przy robieniu projektu na studia. Inna krzywa, która być może jest mniej oczywista, posłużyła do zbudowania bryły obrotowej, która przypomina nieco talerz od perkusji. Kontynuowałem również eksperymenty ze szkłem, czego wynikiem są obiekty o różnych kolorach, stopniach przezroczystości, czy odblaskach. Animacja trwa 25 sekund i składa się z 625 klatek, które renderowały się przez ok. 45 minut. Całkiem sporo, biorąc pod uwagę to, że całą pracę wykonywał nie taki słaby Intel E8400, oraz to, że użyłem POV Ray w wersji 3.7 (beta), która w przeciwieństwie do wersji 3.61 (obecna stabilna) robi użytek z wielu rdzeni procesora. Aż strach pomyśleć ile by to potrwało na moim zabytkowym 600 MHz-owym laptopie ;)

Na tym renderze uwidoczniłem tor poruszania się kamery (startujemy od zielonego końca).
komentarze (0)

Ostatnio za sprawą przedmiotu Grafika interaktywna i wizualizacja 3D zainteresowałem się programem POV-Ray. Jak nietrudno się domyślić, służy on do tworzenia trójwymiarowych scen, a następnie ich renderowania. Niektórzy osiągają w nim tak dobre efekty, że łatwo pomylić ich prace ze zdjęciami (odsyłam do galerii na stronie programu). POV-Ray na tle podobnych programów wyróżnia się kilkoma cechami. Po pierwsze jest zupełnie darmowy, po drugie jest dostępny pod Linuksa. Chociaż na chwilę obecną nie jest zaklasyfikowany jako Wolne Oprogramowanie, to dostępny jest jego kod źródłowy (który w przyszłości chętnie wykorzystam do przyspieszenia programu). Wreszcie po trzecie i najważniejsze - scenę opisujemy za pomocą czegoś, co można nazwać prostym, skryptowym językiem programowania. Tak, dokładnie tak - żadnego klikania. Dobra wiadomość dla takich ludzi, jak ja - mających amatorskie doświadczenie programistyczne...

Oto kilka renderów, które zrobiłem w ostatnich dniach przy pomocy POV-Ray (zachęcam do powięszania).

Bilard, moja pierwsza praca. Dużo kombinowałem ze światłem, stąd tyle cieni i odblasków.

Prosty labirynt, którego zamierzam użyć jako upiększacza prezentacji na projekcie ze wspomnianego na początku przedmiotu.

Moje eksperymenty ze szkłem. Po prawej soczewka, po lewej szklanka (zwracam uwagę na wygładzoną górną krawędź i nieco wklęsłe dno).

Zrobiłem też parę animacji. Nic godnego pokazania, testowałem różne przeloty kamery nad stołem bilardowym. Możemy zadeklarować (wygładzoną) krzywą w przestrzeni i rozkazać kamerze poruszać się wzdłuż niej, gdy użyjemy jeszcze specjalnego makra z bibliotek, kamera będzie zawsze obrócona we właściwą stronę i będzie się przechylać na zakrętach. Jak zrobię jakiś ciekawszy filmik, to na pewno go wrzucę.
komentarze (0)

Jakiś czas temu odkryłem, że nie mogę sprawdzić poczty na GMail'u. Z początku myślałem, że to pewnie jakieś chwilowe problemy na ich serwerze, ale jak sytuacja zaczęła się powtarzać raz za razem, zostałem zmuszony do poszukania innego winowajcy. Kolejnym podejrzanym był mój dostawca internetu. Taką przyczynę zasugerował mi zresztą system pomocy GMail'a, który po kolei zadaje pytania i proponuje rozwiązania. Po serii kilku pytań i rozwiązań, system ostatecznie się poddał, obwiniając mojego dostawcę. Już kiedy miałem się poddać, rozwiązanie przyszło niespodziewanie samo. Gdy dłubałem coś w systemie wyłączyłem czasowo MoBlock'a - linuksowego odpowiednika PeerGuardian'a i... niespodzianka - GMail działa! To jeszcze nie zdenerwowało mnie na tyle, żeby wywalić MoBlock'a, ale jakiś czas później nie mogłem się dostać na FTP serwera, na którym stoi ta strona. Z początku też myślałem, że to awaria, ale awarie nie trwają całymi dniami. Nauczony doświadczeniem spróbowałem z wyłączonym MoBlock'iem i... zadziałało. Dziesięć sekund później na moim dysku nie było już śladu po MoBlock'u. Na dodatek, gdy przeszukałem opcje programu Transmission, to okazało się, że również on ma funkcję blokowania co bardziej złośliwych adresów IP. Dlatego wcale mi nie brakuje MoBlock'a.
komentarze (0)

Przez bardzo długi czas do torrentów używałem Azureusa (dzisiejszy Vuze). Po jakimś czasie, jak wielu innych zauważyłem, że system chodzi znacznie bardziej żwawo, kiedy wspomniany klient jest wyłączony. Tak zaczęło się moje poszukiwanie lżejszego ściągacza torrentów pod Linuksa.
W ten sposób, już dość dawno temu, zacząłem używać klienta KTorrent. Wykombinowałem sobie, że skoro jest napisany w C++ i QT (używam KDE), to przecież nie może zżerać zbyt dużo pamięci, pomimo tego, że to całkiem mocno rozbudowany program. I prawdopodobnie żyłbym sobie tak, w błogiej nieświadomości jeszcze długi czas, gdyby nie mój brat, któremu stosunkowo niedawno zainstalowałem i skonfigurowałem Linuksa. Uświadomił mnie, że na jego komputerze widać ogromną różnicę pomiędzy włączonym, a wyłączonym KTorrentem. To skłoniło mnie do poszukania lżejszego klienta - tak właśnie znalazłem Transmission.
Pierwszą wadą (dla niektórych zaletą) jest to, że został on napisany przy użyciu biblioteki GTK. W moim wypadku oznaczało to raczej niewielką szansę na to, że będzie zajmował mało miejsca w pamięci. Nie zraziłem się jednak i postanowiłem przetestować program. Ku mojemu lekkiemu zaskoczeniu, okazało się, że ma on wszystkie dodatkowe funkcje, z których robię użytek: wybranie tylko części plików z torrenta, priorytety ściągania plików, ograniczanie transferu (globalne i na torrent), najważniejsze statystyki i... to wszystko. Żadnych zbędnych bajerów - wielki plus, za projekt całej aplikacji, naprawdę jestem pod wrażeniem. Transmission bez problemu przeszedł mój test możliwości - nie było przeciwwskazań, abym zaczął go używać.
Na koniec przyszedł czas na test użycia pamięci programem ksysguard (dla niewtajemniczonych: KDE Strażnik Systemu). Przetestowałem oba klienty przy ściąganiu/pobieraniu jednocześnie 4 torrentów (nie były to te same torrenty - test jest orientacyjny). W przypadku KTorrenta pomiaru dokonałem po paru godzinach, a w przypadku Transmission po mniej więcej dobie. Wyniki sprawiły, że doznałem szoku. KTorrent zabierał mi 670 MB RAMu, a co jeszcze gorsze - 50% procesora, co na marginesie jest nie lada wyczynem w przypadku mojego Intela E8400. Transmission za to przywłaszczył sobie 31 MB RAMu i 1-2% procesora.
Od kilku dni brat i ja używamy Transmission i czujemy różnicę.
komentarze (0)

Wydawałoby się, że pomiar temperatury procesora to banalna rzecz. W przypadku (obecnie) najnowszych procesorów Intela z serii Core 2 Duo E8000, okazuje się, że nie jest to wcale takie proste. O co mi chodzi? A o to, że inną temperaturę pokazuje SpeedFan, inną CoreTemp, a inne programy jeszcze inną, co więcej temperatury te zmieniają się jeszcze pomiędzy wersjami programów! A na dodatek różnice nie są małe - sięgają 10 stopni. Nikt kto lubi podkręcać nie może przejść obojętnie wobec takiej rozbieżności temperatur. Skąd się bierze taka różnica?
Najpierw musimy omówić jak przebiega pomiar temperatury za pomocą wewnętrznych czujników procesora (po jednym na każdy rdzeń). Czujnik mierzy temperaturę, a wynik jest umieszczany w odpowiednim rejestrze, który następnie jest odczytywany przez program podający temperaturę. Jednak wartość w rejestrze wcale nie jest temperaturą danego rdzenia. Ta wartość pokazuje ile stopni brakuje do stałej Tj (junction temperature). Innymi słowy wartość z rejestru możemy opisać wzorem: Tj - T, gdzie T to aktualna temperatura. I tu pojawia się problem, gdyż do niedawna nikt nie wiedział ile wynosi Tj. CoreTemp przyjmował (a może dalej to robi?) Tj = 105 st. C dla procesorów z serii E8000. W konsekwencji pomiar temperatury procesora pod obciążeniem na boksowym chłodzeniu dawał powyżej 60 stopni. Gdy to zobaczyłem to nie mogłem uwierzyć, bo wynikałoby z tego, że mój nowy E8400 grzeje się bardziej od poprzedzającego go Athlona XP 2500+ (Barton). Niektóre programy przyjmowały Tj = 100 st. C, ale prawdziwe zdziwienie wywołał twórca programu RealTemp, który przyjął Tj = 95 st. C, co więcej za jego twierdzeniem szły dość mocne argumenty. Przemyślałem sprawę na własną rękę i wyszło mi, że to całkiem realne, żeby Tj wynosiło 95 stopni, jednak parę tygodni temu na Intel Developer Forum ujawniono Tj dla wszystkich procesorów, dla których pozostawało ono nieznane. Tak oto dowiedzieliśmy się, że Tj dla procesorów E8000 wynosi 100 st. C.
Co więc zrobić, aby na pewno mieć poprawny odczyt temperatury? Pod Windowsem chyba najlepiej skorzystać z RealTemp i w ustawieniach zmienić Tj na 100 (RealTemp nie wymaga instalacji). Pod Linuksem natomiast cały czas miałem dobre Tj w lm-sensors. Komenda sensors wypisuje (m.in.): Core 0: +44.0°C (high = +78.0°C, crit = +100.0°C) - temperatura crit zdaje się być odpowiednikiem Tj, poza tym temperatura (przy obciążeniu) odpowiada uzyskanej pod Windowsem, przy pomiarze programem uznającym Tj = 100 st. C.
Na koniec chciałbym zwrócić uwagę na pewien szczegół. Czujniki w procesorach Intela nie są po to, żeby użytkownik mógł sobie sczytać temperaturę procesora, a służą jedynie do załączenia mechanizmów chroniących procesor przed przegrzaniem (thermal throttling, a potem wyłączenie procesora) i tym samym nie są zbyt dokładne, zwłaszcza kiedy temperatura jest daleka od Tj. Może warto zaufać bardziej czujnikowi na płycie głównej?
komentarze (0)

Z okazji niedawnego zakupu nowego komputera musiałem na nowo zainstalować systemy operacyjne. Stwierdziłem, że to dobra okazja do poeksperymentowania - postanowiłem popracować nad rozruchem Linuksa. Pomiar kontrolny wykonany stoperem od wciśnięcia enter w GRUB, do pojawienia się ekranu logowania kdm wykazał 31,36 sekund. W sumie już na starcie wynik był więc całkiem niezły - w artykułach z sieci (co prawda sprzed ok. 2 lat) spotykałem się z czasami powyżej 1 minuty.
Na pierwszy ogień poszło jądro systemu. Zamieniłem 2.6.25 (AMD64) z repo Debiana, na 2.6.26 (AMD64), również z oficjalnego repozytorium. Zmiana niby niewielka i sam nie liczyłem na nic wielkiego, jednak już od jakiegoś czasu chodzą słuchy, że 2.6.26 jest wyraźnie szybsze. Wynik mnie zaskoczył - czas skrócił się do 28,83 sek. Na samej, tak prostej przecież operacji, można już uzyskać 2,5 sekundy różnicy! Na uwagę zasługuje fakt, że już na początku miałem jądro dopasowane do swojego procesora.
Kolejnym etapem było zastosowanie kroków z HOWTO AdeBe z forum Debianowców (powstałego na bazie artykułu z wiki Debiana). Zdecydowanie najważniejszym krokiem jest usunięcie niepotrzebnych usług uruchamianych na starcie. Do określenia, z których można zrezygnować można posłużyć się artykułami o przyspieszaniu Ubuntu i Fedory. W przypadku niektórych usług pozostaje Google i wiki Debiana, oraz odrobina eksperymentów. Pamiętać należy, że wyłączone usługi zawsze możemy potem sami włączyć z konsoli (# /etc/init.d/[usluga] start), warto więc wyłączać także rzeczy z których korzystamy rzadko. Na koniec dodam, że jeśli nie jesteś pewien co robi dana usługa, to lepiej zostaw ją w spokoju. Po zrealizowaniu całego HOWTO czas startu spadł do 24,51 sek., czyli o kolejne 4,32 sek.
Potem wziąłem na warsztat źródło jądra 2.6.26.1 i zacząłem konfigurować. Starałem się wkompilować w jądro jak najwięcej modułów, które i tak przecież muszą być ładowane na starcie. Poszła obsługa systemu plików, sterowniki usb, portu równoległego i inne. Patrzyłem co wypisuje lsmod i starałem się wrzucić te rzeczy do jądra. Efekt był już znikomy, osiągnąłem 24,29 sek, czyli uwzględniając błędy pomiaru można stwierdzić, że nie dało to już poprawy. Próbowałem też przekompilować jądro wykorzystując niezmienioną konfigurację jądra z repozytorium, jednak efekt był o 0,4 sek. gorszy (przypominam o błędach pomiarów!). Daje to do myślenia, jeśli chodzi o opłacalność kompilacji jądra (chyba, że zaczniemy się bawić w zaawansowane opcje optymalizacji kompilatora).
Na koniec stwierdziłem, że podczas startu zamiast ton przewijanego tekstu miło byłoby mieć splasha. Pamiętam, że kiedyś skonfigurowanie takiego miłego akcentu było całkiem skomplikowane, ale obecnie jest splashy i wystarczy jedynie parę komend. Dodam, że sprawdzałem i splashy nie powoduje mierzalnego wydłużenia startu systemu (wydłuża mniej, niż wynosi błąd pomiaru stoperem).
Podsumowując uzyskałem przyspieszenie startu o 7 sekund. Stosunkowo niedużo, jednak jest to odczuwalne. Dodam, że cały ten wpis to jedynie wierzchołek góry lodowej, bo możliwości przyspieszania startu idą znacznie dalej o czym być może coś napiszę innym razem.
komentarze (0)