Raspberry PI jako desktop sprawdzało się do tej pory średnio – I/O dysku na poziomie 30MB/s bez perspektywy poprawienia jakimikolwiek rozszerzeniami przekreślała. Kilka tygodni temu sytuacja się zmieniła i mamy PI 4. Jak się na nim pracuje?
Od kilku tygodni jestem szczęśliwym posiadaczem dwóch malin w wersji 4. Pierwsza, z 1GB ramu sprawuje się bardzo dobrze hostując storage m.in. tego bloga. W zestawie z kilkoma innymi Raspberry PI 3, dedykowanym zasilaczem usb 40W od Tp-linka i dyskiem 2 TB daje sobie radę dość dobrze. Albo po prostu mi nie przeszkadza trochę dłuższe ładowanie strony 🙂 Udało się na to wepchnąć kilka wordpressów, NAS, build server i jeszcze pare innych rzeczy.
Drugie PI4 czekało na lepsze czasy. Miało posłużyć jako hosting do bardziej wymagających stron, jednak między czasie plan się zmienił i stronki czekają na lepsze czasy. Pozostało zatem skorzystać z okazji i podpiąć je w miejsce starego, popsutego już macbooka i zobaczyć czy da się na tym pracować.
Da się 🙂
Oprócz kilku drobnych problemów, m.in. ze starą wersją firefoxa, brakiem ładnego środowiskai brakiem niektórych sterowników, m.in. do drukarki, RPI4 jako desktop sprawuje się całkiem znośnie. Dobra, może ktoś lubi MATE lub Xfce4, wtedy ma jeden problem mniej.
Bardzo duży zysk na wydajności daje włożenie dysku SSD. O ile w RPI 3 nie miało to większego sensu (bo USB 2.0 i tak obcinało transfer do 30MB/s), to malina w wersji 4 daje radę wyciągać 200-330MB/s. Do tego dochodzi płynnie działająca sieć, która nie współdzieli transferu z dyskiem i mamy całkiem przyjemnie pracujący desktop. Uruchomienie SSD wymagało co prawda dopisanie następującego stringa w /boot/cmdline.txt:
usb-storage.quirks=125f:a68a:u
i zabawę w kopiowanie systemu plików z karty SD na dysk, ale zwróciło się szybko w wydajności. Co więcej, karty SD nie dają takich transferów, więc zainwestowanie w dysk SSD dla maliny jest moim zdaniem dobrym krokiem.
A po instalacji…
Po zainstalowaniu Raspbiana Buster pozostaje doinstalować dosłownie kilka niezbędnych programów, m.in. ssh, openvpn, git, gcc, make, cmake, qtcreator, mate-desktop, mate-desktop-environment, libreoffice-writer, chromium-browser, mate-terminal, whois, imagemagick, htop, screen, nmap, tcpdump, fish oraz skonfigurować wifi w /etc/wpa_supplicant i /etc/network/interfaces aby cieszyć się gołym desktopem. Aby cieszyć się jeszcze bardziej i poczuć jak na początku tego tysiąclecia, wypadało jeszcze pobrać z mate-look.org kilka zestawów ikon oraz theme dla środowiska Mate. Następnie rozpakować je, do odpowiednio: /usr/share/icons i /usr/share/themes.
Wisienką na torcie jest oczywiście wywalenie z /etc/passwd domyślnego basha, wsadzenie tam fisha dla swojego konta (no tak, jeszcze konto pi trzeba usunąć i dodać swoje) i skonfigurowanie mate-terma ze swoimi ulubionymi skrótami.
Uf. Jak 15 lat temu, pół dnia roboty i desktop wygląda, nie wstyd się zalogować przy znajomych.
Wydajność
Jak wspomniałem, SSD daje kopa wydajności jeśli chodzi o dostęp do plików, uruchamianie programów itd. w stosunku do RPi 3. Natomiast po chwili użytkowania zaczynają wkurzać niewielkie lagi przy zmianach i włączaniu aplikacji, które trwają ok. pół sekundy, czasami ciut dłużej. Nie ma tego na zwykłym desktopie, nawet z włączonymi efektami pulpitu. Skąd tu się bierze – nie wiem. Może to brak cache w cpu, a może brak wsparcia grafiki w wyświetlaniu okienek?
Koniec końców da się jednak żyć z tym komuterkiem, jeśli tylko małę lagowanie i brak aktualnych wersji niektórych programów nie przeszkadza. Co więcej, kompilacja frameworka dinemic i innych aplikacji, nad którymi ostatnio pracuję przebiega tu dość sprawnie, nawet szybciej niż na moim zwykłym desktopie. Oczywiście kompilator wypluwa binarki w wersji ARM, ale to już inna bajka. Nie przeszkadza to również w normalnej pracy w przeglądarce i oglądaniu głupich obrazków, gdy kompilator zjada 400% CPU.
Podsumowując, jeśli ktoś nie ma wymagań co do grania i oglądania wideo (od biedy też się da), to idzie przeżyć z samym RPi 4. Jeśli chodzi o hosting, to jest znacznie lepiej i daje nieporównywalnego kopa w stosunku do RPi 3 zarówno jako sam hosting dynamicznych stron jak i NAS.
Na koniec dorzućmy UPS’a
Wspomniany na początku klaster RPi zastąpił starego dobrego HP G6, który robił za build server, hosting i całą resztę rzeczy na potrzeby projektów z cloudover. Po drodze przyplętał się UPS, 1500VA / 900W, który mógł podtrzymać serwer HP przez około 50 minut. Po wymianie na kilka raspberry PI i przekonfigurowaniu całego środowiska testowania i budowania czas wydłużył się… do 15 godzin 🙂