Linux - Real-Time (?)

Linux - Real-Time (?) Marcin Bis marcin@bis.org.pl 6 marca 2012 Marcin Bis Linux - Real-Time (?)

O czym to będzie? Linux w systemach wbudowanych (głównie) dużo gotowego oprogramowania w wielu przypadkach system działa z pudełka popularność Coraz więcej aplikacji potrzebuje czasu rzeczywistego czyli gwarantowanych maksymalnych opóźnień (o tym za chwilę) równocześnie chcielibyśmy zachować łatwość programowania w Linuksie

Dla przypomnienia: Tak wygląda nasz system (dystrybucja)

O mnie Marcin Bis http://bis.org.pl/ GNU/Linux (administracja, programowanie) szkolenia, konsulting, wsparcie techniczne zastosowanie Linuksa w przemyśle (real-time)

Po kolei... 1 Co oznacza Real-Time? 2 Z czym się zmagamy - podstawowe pojęcia. 3 Rodzaje wejścia-wyjścia. 4 Praktyczny test. 5 Jak z Linuksa zrobić system Real-Time? 6 Obowiązkowy przykład.

Co oznacza Real-Time? Definicja książkowa : Poprawność wykonania operacji zależy nie tylko od tego, czy wykonała się bez błędów i zwróciła poprawny rezultat, ale także od czasu (górnego ograniczenia) w jakim operacja się zakończyła.

Co oznacza Real-Time? Definicja praktyczna : System RT, to taki, w którym da się udowodnić, że każda wymagana operacja zakończy się w określonym czasie. W idealnym przypadku jest to dowód matematyczny. Niestety przy złożoności współczesnych systemów jest to niewykonalne, a nawet jeżeli, to istnieje ryzyko popełnienia błędu podczas dowodzenia. W praktyce stosuje się zestaw testów. System, który przejdzie takie testy określne w specyfikacji lub powstające podczas jego tworzenia, jest określany jako system czasu rzeczywistego.

Real-Time vs. Real-Fast Linux jest zaprojektowany jako system demokratyczny zasoby są przydzielane według potrzeb na przykład: planista zapobiega zagłodzeniu procesu Zazwyczaj determinizm nie jest brany pod uwagę liczy się maksymalna wydajność (throughput) Np.: dolne połówki w obsłudze pakietów sieciowych

Co ma do tego Linux? Przykładowy system oparty na projekcie TNKernel http://www.tnkernel.com/ Projekt Open-Source rozwijany głównie przez jednego człowieka (plus zainteresowane nim firmy). Elegancko zaprojektowany, przejrzysty kod. Przetestowany na wielu wdrożeniach. Problem Klient zamawia: pobieranie logów przez FTP zdalne sterowanie urządzeniem Zbyt trudne do zrealizowania (w rozsądnym czasie). Te rzeczy mamy z pudełka w Linuksie! - sprawdźmy, czy się nadaje.

Podstawowe pojęcia.

Deadline Punkt w czasie, w którym dana akcja ma nastąpić (np. reakcja na zmianę stanu wejścia). Hard Real-Time - operacja zawsze musi zakończyć się w określonym czasie. Wynik operacji zakończonej później - nie nadaje się do wykorzystania (awaria już nastąpiła). Soft Real-Time - okazjonalnie operacja może zakończyć się po ustalonym czasie (błąd nie jest krytyczny dla operacji) - na przykład zgubiona ramka obrazu.

Latency Czas pomiędzy momentem w którym akcja miała wystąpić, a momentem w którym w rzeczywistości wystąpiła. W idealnym przypadku (taki system nie istnieje) - opóźnienia byłyby zerowe. W rzeczywistości komputer potrzebuje pewnego czasu na ustabilizowanie i przetworzenie sygnałów ze sprzętu, oprogramowanie wprowadza własne opóźnienia itp.

Jitter Wariancja opóźnienia (poprzedniej wartości). Czas pomiędzy wystąpieniem przerwania (zgłoszeniem przez sprzęt) a uruchomieniem procedury jego obsługi nie jest stały. Jego zmienność jest równie groźna jak duże opóźnienie (na przykład uniemożliwia wykorzystanie systemu do akwizycji danych).

Predictability Przewidywalność. Oznacza wiedzę na temat tego ile czasu zajmie operacja (na przykład procedura obsługi przerwania). Teoria algorytmów zajmuje się określaniem złożoności obliczeniowej poszczególnych metod. W szczególności aby system był przewidywalny, konieczne jest używanie algorytmów działających w stałym czasie (niezależnym od ilości danych).

Worst Case Ze względu na zmienność rzeczywistych systemów (nie da się zbudować systemu idealnego), głównym polem naszych zainteresowań pozostaje najgorszy możliwy przypadek. System będzie działał w sposób przewidywalny jeżeli będziemy znać jego opóźnienie w najgorszym możliwym przypadku.

Rodzaje wejścia-wyjścia

Próbkowane wejście powtarzaj jeżeli odczyt > wartość graniczna to: /* czujnik znajduje się nad podłogą */ poruszaj się do przodu skręcając lekko w lewo w przeciwnym wypadku: /* czujnik znajduje się nad linią */ poruszaj się do przodu skręcając lekko w prawo

Próbkowane wejście c.d.

Marcin Bis (http://bis.org.pl/) Linux - Real-Time (?)

Wejście sterowane przerwaniami Metoda stosowana w większości systemów - brak problemów wynikających z obciążania głównej pętli operacjami pobocznymi.

Praktyczny test

Wzorcowy układ

Wzorcowy układ Będziemy rozważać następujący układ: Wejście jest wzbudzane sygnałem i system reaguje zmieniając stan wyjścia. W tym przypadku są to PIN-y GPIO. ale sytuacja niczym się nie różni od wzbudzania wejścia przy pomocy innego (wewnętrznego mechanizmu). To jest timera lub przerwania z urządzenia (kamera).

Realizacja w procedurze obsługi przerwania

Dodajemy obciążenie $ cat /proc/loadavg 5.02 3.76 2.04 2/47 432 odczyt danych z karty SD: cat /dev/mmcblk0p1 > /dev/null wysyłanie danych ASCII na terminal podłączony przez port szeregowy: cat /dev/zero od -v wysyłanie do badanego systemu dużej ilości pakietów IP (ICMP): ping -f <adres urządzenia> Uwaga!: te testy nie poddają systemu obciążeniom występującym podczas rzeczywistej pracy.

Realizacja w procedurze obsługi przerwania - obciążenie

Oddzielamy logikę od mechanizmów

Userspace

Userspace - obciążenie

Jak z Linuksa zrobić system Real-Time? Przy pomocy rozwiązań Open-Source

Metody oparte na mikrojądrze: RTLinux - pierwsza implementacja. RTAI - najmniejsze możliwe opóźnienia. Adeos - nanokernel. Xenomai - oparty o Adeos - łatwe portowanie kodu z innych systemów RT. Próba ulepszenia Linuksa: RT PREEMPT

Xenomai - architektura

RT PREEMPT

Już od wersji 2.6.0 dostępna jest możliwość włączenia wywłaszczania kodu jądra. Kernel Features ---> Preemption Model (Preemptible Kernel ()) --> ( ) No Forced Preemption (Server) ( ) Voluntary Kernel Preemption (Desktop) (X) Preemptible Kernel (Low-Latency Desktop) To nadal nie jest RT!

Bez wywłaszczania

Z wywłaszczaniem

RT-Preempt Standardowe jądro z omówionymi opcjami minimalizuje opóźnienia, jednak nie spełnia nawet wymogów miękkiego systemu czasu rzeczywistego. Zapewnia całkiem dobrą, ale nadal nie gwarantowaną responsywność. Łaty pozwalające na uruchamianie wątków czasu rzeczywistego, rozwijane są w oddzielnym projekcie: http://www.kernel.org/pub/linux/kernel/projects/rt/ Są one sukcesywnie włączane do jądra.

Konfiguracja Kernel Features ---> Preemption Mode (Complete Preemption ()) ---> (X) Complete Preemption (Real-Time) -*- Thread Softirqs -*- Thread Hardirqs

Przerwania w wątkach 1 Standardowa obsługa przerwań 2 Obsługa przerwań w wątkach

Obciążenie

Opóźnienia w systemie

Jądro z łatą RT PREEMPT nie sprawia, że system staje się RT. Trzeba skorzystać z: POSIX RT-API i dopiero aplikacje napisane z jego użyciem będą działały w reżimie czasu rzeczywistego!

Wsparcie dla POSIX RT API w Linuksie W celu zapewnienia wsparcia dla aplikacji czasu rzeczywistego, został opracowany standard IEEE 1003.1b - POSIX.1b. Najważniejsze deterministyczne mechanizmy programowania w systemach czasu rzeczywistego określone w standardzie, to: Planowanie uruchamiania procesów (API planisty, pozwalające zdefiniować na stałe priorytet procesu oraz klasę zaszeregowania). Blokowanie pamięci (w celu uniemożliwienia jej zeswapowana). Kolejki komunikatów. Pamięć współdzielona. Sygnały czasu rzeczywistego. Semafory. Timery (CLOCK MONOTONIC). AIO - nieblokujące operacje odczytu i zapisu danych, oraz kontroli zleceń

Pozostałe problemy

Inwersja priorytetów Inwersja priorytetów - występuje w momencie kiedy zadanie (P1) o wysokim priorytecie wywłaszcza zadanie o niższym (P2), przetrzymujące blokadę (semafor), do której równocześnie chce się dostać zadanie z wyższym priorytetem.

Inwersja priorytetów

Problemy sprzętowe SMI - przerwanie obsługiwane przez bios (na przykład włączenie wentylatora lub przyjęcie danych z klawiatury USB, o ile została skonfigurowana do obsługi przez BIOS). Problem występuje głównie w PC. Wyłączenie tego typu przerwań (czasem jest możliwe przy pomocy interakcji z ustawieniami BIOS-u lub ACPI) może doprowadzić do uszkodzenia sprzętu. VGA - konsola VGA może generować opóźnienia rzędu 1ms jądro powinno korzystać z konsoli szeregowej. (problem nie występuje podczas korzystania ze środowiska graficznego ani z bufora ramki - wynika z błędów projektowych BIOS-u VGA). DMA - coś innego niż procesor kontroluje transfery z/do pamięci.

Problemy sprzętowe - DMA

Zatrzymanie awaryjne