Przy ekstremalnej konfiguracji, czyli base_period=10000 i synale na LPT w okolicach 100 kHz spodziewałem się obciążenia procesora w okolicach 100%.
Po pierwsze, obsługa LPT trwa zawsze tyle samo, ale czym częściej się ja wywołuje, tym mniej czasu pozostaje procesorowi na wykonanie innych czynności, z tym że nierobienie niczego też jest czynnością.
Po drugie jest jakaś graniczna liczba wywołań w jednostce czasu, po przekroczeniu której procesor musiałby zaczynać nowy proces chociaż jeszcze nie skończył poprzedniego.
Przy base_period=8500 komputer mi się już zawieszał, więc ta granica na moim sprzęcie jest gdzieś w okolicach 8500<base_period<10000.
Najpierw Ryzen5 3400G, cztery rdzenie fizyczne, osiem wątków logicznych, ~4GHz zegar.
System Xubuntu 18.04, kernel rt-preempt 5.2.21-rt13.
Kernel uruchomiony z parametrem isolcpus=6,7 czyli wyłączenie czwartego rdzenia fizycznego z schedulera systemu operacyjnego i pozostawienie go do wyłącznej dyspozycji wątku czasu rzeczywistego.
Po uruchomieniu linuxcnc wyglądało to następująco :
Natomiast po zamknięciu linuxcnc tak :
Tutaj absolutnie żadnego zaskoczenia nie ma.
Na biegu jałowym wszystkie rdzenie są obciążone poniżej jednego procenta, natomiast po uruchomieniu linuxcnc rdzeń czasu rzeczywistego jest obciążony prawie w stu procentach, natomiast pozostałe rdzenie obsługują axis i wykorzystują w granicach 6-7% swoich możliwości.
Teraz Athlon II X2, dwa rdzenie fizyczne, dwa wątki logiczne, ~3GHz zegar.
System Xubuntu 18.04, kernel Rtai 4.14.148-rtai-amd64.
Kernel uruchomiony z parametrem isolcpus=1 czyli wyłączenie drugiego rdzenia fizycznego z schedulera systemu operacyjnego i pozostawienie go do wyłącznej dyspozycji wątku czasu rzeczywistego.
Najpierw na biegu jałowym :
Tutaj akurat obciążenie jedynego aktywnego rdzenia skoczyło ponad 6%, ale średnio jest dużo mniej.
Natomiast po uruchomieniu linuxcnc zobaczyłem coś, czego się nie spodziewałem :
Bynajmniej nie chodzi o ten kretyński komunikat "RTAPI:ERROR", który mnie tylko wnerwia, w ogóle nie wierzę w jego rzetelność i przy następnych kompilacjach linuxcnc będę najzwyczajniej wycinał fragment kodu odpowiedzialny za jego wyświetlanie.
Chodzi o to, że drugi rdzeń, ten od wątku czasu rzeczywistego, jak zaklęty pokazuje 0% obciążenia ...
Ponieważ jest to absolutnie niemożliwe, zrobiłem taki numer, że zrestartowałem komputer, ale tym razem uruchomiłem kernel z parametrem isolcpus=0, czyli w praktyce zrobiłem procesor jednordzeniowy.
Tym razem monitor systemu pokazał prawdę :
No cóż, okazuje się, że w przypadku komputera "widziałem na własne oczy" nie przesądzą że to prawda ...
Jeszcze tylko krótkie wyjaśnienie, Ryzena uruchamiam z kernelem rt-preempt, bo grafiki Vega 11 nie obsługuje kenel starszy od 5.0, natomiast w tym starym komputerze z Athlonem jest zintegrowany jakiś badziewny Radeon, który nie wymaga najnowszego kernela, więc mogę zastosować Rtai, które nie udostępnia łat na kernel nowszy od 4.14.148 właśnie.
Jak widać monitor systemu na kernelu rt-preempt pokazuje właściwie, a na kernelu rtai pokazuje bzdury ...
Oczywiście nie znam dokładnie przyczyny takiego stanu rzeczy, ale uznałem że warto się tą obserwacją podzielić, przy okazji wyjaśniając kilka dość istotnych kwestii.
