.ANALYSIS OF REAL-TIME MULTIMEDIA APPLICATIONS WORKING IN LINUX

ZESZYTY N A U K O W E POLITECHNIKI ŚLĄSKIEJ Seria: IN FO R M A TY K A z. 38

2000 N r kol. 1451

Janusz K A RM A Ń SK I

Politechnika Śląska, Instytut Informatyki

ANALIZA PRACY APLIKACJI M ULTIM EDIALNYCH CZASU RZECZYW ISTEGO W SYSTEM IE LINUX

S treszczenie. Artykuł prezentuje analizę pracy aplikacji m ultim edialnych czasu rzeczyw istego w system ie Linux. Przedstaw ione zostały wykresy opóźnień uzyskiw anych przy przetw arzaniu i transm isji inform acji m ultim edialnej, w zależności od obciążenia systemu. N astępnie wskazano, o ja k ie cechy pow inno zostać wzbogacone jąd ro systemu, aby popraw ić w ydajność pracy aplikacji m ultim edialnych.

.ANALYSIS OF REAL-TIME MULTIMEDIA APPLICATIONS WORKING IN LINUX

S u m m a ry . This paper presents analysis o f distributed m ultim edia application w orking in Linux. Delays observed in com puting and transm ission o f m ultim edia inform ation in function o f system load are presented. F inally m ethods o f im proving perform ance o f m ultim edia applications are proposed.

1. W stęp

A plikacje m ultim edialne czasu rzeczywistego staw iają now e w ym agania dla system ów operacyjnych, pod kontrolą których pracują. Przykładem m o g ą być w ideokonferencje pozw alające na kom unikację w czasie rzeczyw istym pom iędzy ludźm i znajdującym i się nieraz w znacznym oddaleniu od siebie, np. w dom u i w biurze. Ten typ aplikacji je s t bardzo w rażliwy na opóźnienia pow stające w rozproszonym system ie m ultim edialnym , poniew aż inform acja m ultim edialna je s t generowana w czasie rzeczyw istym (np. z kam ery) i m usi być na bieżąco konsum ow ana (np. w yśw ietlana na m onitorze). K onieczne je s t zapew nienie stałego czasu transm isji, czyli stałego opóźnienia każdej porcji inform acji m ultim edialnej transm itow anej w sieci. Inaczej mówiąc, dane m ultim edialne s ą w ażne tylko przez pewien

krótki okres czasu, po upływ ie którego stają się bezużyteczne, i jeżeli nie zostały odtworzone na kom puterze użytkow nika, m u szą być porzucone.

W ostatnich latach prowadzonych je st w iele prac badaw czych na polu zapewnienia gwarancji QoS dla aplikacji m ultim edialnych. W iększość z tych prac koncentruje się na infrastrukturze sieciow ej, czyli na zapew nieniu jakości połączeń w sieci. Najlepszym przykładem je st tu sieć ATM , od początku zaw ierająca w budow ane odpowiednie m echanizm y zarządzania ja k o ścią naw iązywanych połączeń.

Podczas gdy system y transportow e zajm ują się przesyłaniem danych, system y końcowe odpow iedzialne są za ich przetw arzanie, ja k np. kom presja i dekom presja, oraz prezentow anie użytkow nikow i - m iędzy innymi odtw arzanie obrazu i dźw ięku. Systemy te pow inny w ięc przetw arzać strum ienie m ultim edialne w czasie rzeczyw istym , tak aby zapewnić w ym aganą jakość usług aplikacjom m ultim edialnym . W ażn ą k w estią jest w yposażenie sam ego system u operacyjnego w zm odyfikow ane m echanizm y zarządzania zasobam i, pozw alające aplikacjom negocjow ać ilość przydzielonych im zasobów , takich jak czas procesora, pam ięć fizyczna czy interfejs sieci, oraz dającym pew ne gw arancje, że wynegocjow ane dla aplikacji param etry QoS b ęd ą realizowane.

W niniejszej pracy podjęta została próba znalezienia odpow iedzi na pytanie, jak zm inim alizow ać czas przetw arzania danych m ultim edialnych w system ie, tak aby np.

•efektyw nie wykorzystywać połączenie w sieci o zagw arantow anej przepustow ości i param etrach QoS.

Przy ocenie jakości pracy aplikacji m ultim edialnych w ykorzystane zo stan ą w dalszej części pracy m iędzy innym i terminy: opóźnienie oraz w ahania opóźnienia [1], Całkowite opóźnienie je s t to odstęp czasu m iędzy rejestracją pewnej porcji inform acji m ultim edialnej w punkcie w ejściow ym system u a odtw orzeniem tej inform acji w punkcie wyjściowym.

Przykładowo, dla w ideokonferencji je s t to czas m iędzy zeskanow aniem jednej klatki obrazu przez kam erę a w yśw ietleniem tej klatki na m onitorze innego użytkownika. M ożna tu mówić zarówno o średnim opóźnieniu w pew nym przedziale czasu, ja k i o opóźnieniu m inim alnym i m aksymalnym.

W ahania opóźnienia m ożna zdefiniow ać jako różnicę m iędzy m aksym alnym i m inim alnym opóźnieniem . W ystępowanie znacznych odchyleń od uzgodnionego średniego opóźnienia pow oduje przerw y w ciągłym odtw arzaniu inform acji m ultim edialnej.

2. Budowa testowej aplikacji multimedialnej dla system u Linux

Jako platform ę badań zdecydowano się w ykorzystać system operacyjny Linux pracujący na kom puterach PC. W ybór system u Linux podyktow any został d u żą je g o popularnością

Analiza pracy aplikacji m ultim edialnych czasu rzeczyw istego w system ie Linux 135

dostępnością w ielu aplikacji oraz kom pletnego kodu źródłow ego system u niezbędnego przy w prow adzaniu planow anych zm ian do jądra, m ających na celu w zbogacenie m echanizm ów zarządzania zasobam i o elem enty gwarancji jakości usług.

T estow ana aplikacja składa się z kilku niezależnych procesów realizujących różne zadania zw iązane z przetw arzaniem i transm isją danych m ultim edialnych. Schem at aplikacji przedstaw iony je st na rysunku 1.

Rys. 1. Schem at aplikacji testowej Fig. 1. Test application schem a

Interfejs użytkow nika stw orzony został przy użyciu funkcjonalnej biblioteki Q T dostępnej bezpłatnie dla system u Linux. C entralny proces w yśw ietla okienko głów ne aplikacji w yposażone w m enu, z którego użytkownik w ybiera polecenia sterujące p rac ą aplikacji.

Polecenia te są następnie przekazyw ane do właściw ych procesów odpow iedzialnych za ich realizację za pom ocą m echanizm u przesyłania kom unikatów . P rzez w iększość czasu proces ten je st zaw ieszony w tzw . kolejce kom unikatów w oczekiw aniu na akcję użytkow nika, nie konsum uje on w ięc czasu procesora. Dopiero po w ybraniu przez użytkow nika np. polecenia z menu proces otrzym uje odpow iedni kom unikat od system u i po przetw orzeniu polecenia użytkownika przesyła odpow iednie kom unikaty do w łaściw ych procesów , aby następnie powrócić do stanu oczekiwania.

O peracje kom presji/dekom presji oraz przesyłania i odbierania danych z sieci zostały rozbite na odrębne procesy. Dzięki tem u w strzym anie pracy jednego procesu na blokującej

operacji w ejścia-w yjścia nie pow oduje zatrzym ania pracy pozostałych - np. dekom presja odebranej z sieci klatki obrazu wideo może odbywać się jednocześnie z odbieraniem następnej. Porcje przetw orzonej inform acji m ultim edialnej przekazyw ane s ą pomiędzy procesam i odpow iedzialnym i za kom presję i wysyłanie oraz odbieranie i dekom presję za pom ocą standardow ego m echanizm u strum ieni dostępnego w system ach U n ix ’owych.

Poniew aż operacja digitalizacji każdej kolejnej klatki obrazu w ideo przez kartę w ejściow ą realizow ana je s t sprzętow o „w tle” pracujących w system ie procesów, nie m a potrzeby urucham iania osobnego procesu dla digitalizacji obrazu.

Do kom presji obrazu wideo wykorzystano ogólnie dostępną bibliotekę libjpeg - kolejne klatki obrazu przed wysłaniem kom presow ane są do form atu JPEG. T en sposób kompresji ruchom ego obrazu w ideo (znany pod nazw ą M JPEG ) charakteryzuje się w iększą ilością transm itow anych danych niż w przypadku M PEG2, wykorzystującego przy kompresji zależności m iędzyram kow e, oraz H.261, zaprojektow anego specjalnie dla w ideokonferencji.

Z drugiej strony szybkość (program owej) kom presji dla M JPEG je st w iększa niż w przypadku M PEG2, a z kolei jak o ść obrazu je st wyraźnie lepsza niż w przypadku H.261 stosującego duże uproszczenia w algorytm ie kom presji. F orm at M JPE G je s t także odporniejszy na błędy transm isji - poniew aż każda klatka obrazu transm itow ana je st w całości, zagubienie jednej z nich podczas transm isji nie m a w pływ u na odtwarzanie

•następujących po niej.

3. Sposób dokonywania pomiarów

Tak stw orzoną aplikację należało następnie wyposażyć w m ożliw ość rejestracji czasów realizacji poszczególnych zadań, czasów przydziału procesora dla poszczególnych procesów, oraz poszerzyć o funkcje generacji odpow iednich w ykresów i statystyk.

Pierwszy napotkany problem dotyczył m ożliw ości (a raczej jej braku) precyzyjnego pom iaru czasu w system ie Linux. M aksym alną m ożliw ą standardow o rozdzielczość ofetuje funkcja system ow a tim esO zw racająca ilość „tyknięć” zegara system ow ego od m om entu uruchom ienia systemu. P oniew aż zegar systemowy w L inux’ie pracującym na platform ie PC zlicza im pulsy dokładnie co 1/100 sekundy (z tak ą częstotliw ością generow ane jest przerw anie zegarow e), m ożna wykonywać w ten sposób pom iary z dokładnością nie w iększą niż w spom niana 1/100 sekundy. A by uzyskać w iększą dokładność pom iaru m ożna między innymi odczytyw ać bezpośrednio wartość odpow iedniego rejestru układu czasowego generującego przerw ania zegarowe.

Poniew aż ze w zględów bezpieczeństw a w systemie Linux dostęp do urządzeń (portów we-wy) m ożliw y je st jedynie przez ją d ro system u oraz m oduły ładow ane dynam icznie

Analiza pracy aplikacji m ultim edialnych czasu rzeczywistego w system ie Linux 137

pracujące w jego przestrzeni, stworzony został odpow iedni m oduł zw racający bieżącą wartość w spom nianego rejestru za pośrednictw em pliku specjalnego /dev/tim er. D ocelowe rozw iązanie pow inno polegać na wyposażeniu samego ją d ra system u w łatw iejszą w użyciu funkcję systemową.

Inny napotkany problem dotyczył synchronizacji czasu kom unikujących się ze sobą kom puterów. A by prześledzić dokładnie ca łą drogę klatki wideo od digitalizacji i kom presji na jednym kom puterze do dekom presji i w yśw ietlenia na drugim , konieczne byłoby bardzo precyzyjne (zależnie od wymaganej dokładności pom iarów ) zsynchronizow anie zegarów kom unikujących się kom puterów . Poniew aż przy dokładności pom iarów 1/1000 sekundy je st to bardzo trudne, zdecydow ano się na jednym z kom puterów uruchom ić program odbijający nadchodzące ramki z pow rotem do ich nadawcy (rysunek 2). W ten sposób w ideokonferencja prowadzona je st „z sam ym sobą” , ale wydaje się, że nie m a to w iększego w pływu na wykonywane analizy przepływ u inform acji m ultim edialnej, oczyw iście poza w pływ em na sam czas transm isji ram ek w sieci.

Rys. 2. Stanow isko badaw cze Fig. 2. Research configuration

4. Poprawa płynności odtwarzania poprzez w prow adzenie dodatkowego bufora klatek wideo

W celu zbadania całkow itego opóźnienia transm isji i przetw arzania klatek wideo nawiązano połączenie w opisany wyżej sposób. Rysunek 3.a przedstaw ia w ykres opóźnienia podczas konferencji o param etrach 10 klatek na sekundę, rozm iar klatki 300x200, 256 odcieni szarości. O bciążenie procesora w trakcie eksperym entu oscylow ało w okół 70%. Duże wahania opóźnienia w idoczne na wykresie pow odują niezbyt płynne odtw arzanie obrazu na ekranie m onitora.

Rys. 3. O późnienie a) bez bufora, b) po w prow adzeniu bufora klatek w ideo Fig. 3. Latency a) without buffer, b) with video frames buffer

Aby zniw elow ać w pływ wahań opóźnień poszczególnych klatek oraz popraw ić płynność odtw arzania, zastosow any został dodatkow y bufor przechow ujący klatki w ideo po ich dekom presji, a przed odtw orzeniem . Zadaniem odrębnego procesu je s t cykliczne pobieranie w ustalonych m om entach czasu klatek z bufora i w yśw ietlanie ich. Sam bufor zrealizowany . je st w bloku pam ięci wspólnej, współdzielonej pom iędzy procesam i dekom presji oraz wyświetlania. P oniew aż w systemie Linux pam ięć w spólna realizow ana je s t bezpośrednio w pam ięci fizycznej system u, a ponadto operacja kom presji w ykonyw ana je s t w prost do w spom nianego bufora, zaś wyświetlanie obrazu bezpośrednio z niego, nie m a żadnego dodatkowego narzutu czasowego związanego z kopiow aniem danych do i z bufora. Do synchronizacji dostępu procesów do bufora w ykorzystyw any je s t m echanizm sem aforów.

Display Process

Decompress Process RSiBTS

Receive from network Process

T "

Rys. 4. Bufor w ideo Fig. 4. Video buffer

Monitor

A naliza pracy aplikacji m ultim edialnych czasu rzeczyw istego w system ie Linux 139

Po ustaleniu opóźnienia na pew ną wartość, np. 200 m s, każda ram ka zostanie w yświetlona dopiero po danym czasie od jej digitalizacji - naw et jeżeli jej dekom presja zakończy się wcześniej, będzie ona czekać w buforze. D zięki tem u otrzym ujem y równom ierne i płynne dla użytkownika wyśw ietlanie obrazu wideo, jedynie klatki, których całkowity czas transm isji i przetw arzania (kom presji/dekom presji) przekroczy ustalony czas, spow odują zachw ianie płynności odtwarzalna. K osztem pow yższego rozw iązania jest zw iększenie całkow itego opóźnienia, z jakim inform acja m ultim edialna je s t dostarczana dla użytkownika, dlatego istotne je s t wyważone dobieranie wartości ustalonego opóźnienia na zasadzie kom prom isu m iędzy niezbyt płynnym odtw arzaniem a zbyt dużym opóźnieniem [8].

N a rysunku 3.b przedstaw iono opóźnienia uzyskane po w prow adzeniu do aplikacji bufora klatek w ideo. M ożna zauważyć, że po użyciu bufora wykres popraw ił się, choć nadal daleko mu do ideału. W idoczne na wykresie chw ilowe duże skoki opóźnienia spow odow ane są dużym czasem transm isji niektórych klatek wideo w sieci. N atom iast zam iast oczekiw anych 200 m s opóźnienie wynosi średnio praw ie 230 ms, wykres nie je s t rów nież całkiem gładki.

Jedną z przyczyn je s t działanie funkcji systemowej nanosleep() używanej do budzenia w określonych m om entach procesu w yświetlającego gotowe klatki pobierane z bufora. Sposób im plem entacji tej funkcji nie daje żadnej gwarancji, kiedy dokładnie procesor zostanie ponownie przekazany uśpionem u za jej pom ocą procesowi - czas podaw any ja k o jej param etr mówi jedynie, ja k długo „co najm niej” m a spać proces, w rzeczyw istości m oże to trwać jednak dłużej. Ponadto należy zauważyć, że ta sam a funkcja nanosleep() je s t w ykorzystyw ana przez proces odpow iedzialny za digitalizację i kom presję kolejnych klatek obrazu z karty wejściowej w ideo do usypiania w oczekiw aniu na m om ent digitalizacji kolejnej klatki. W efekcie ju ż na sam ym początku m om enty digitalizacji kolejnych klatek są obarczone pewnym błędem. Rozw iązaniem pow yższych niedokładności wydaje się być w yposażenie system u w m ożliw ość autom atycznego cyklicznego aktyw ow ania niektórych procesów , w zależności od potrzeb aplikacji m ultim edialnych, np. dokładnie x razy na sekundę.

5. Analiza czasów przydziału procesora dla poszczególnych zadań

Aby określić faktyczny czas realizacji poszczególnych etapów przetw arzania i transm isji informacji m ultim edialnej, zm ierzono czasy ich rozpoczęcia i zakończenia. Otrzym ane wyniki różnią się znacznie w zależności od obciążenia procesora oraz param etrów pracy programu. W ynik dla trzech kolejnych klatek w ideo przy rozm iarze klatki 300x200, 24bit ow ym kolorze, i 8 ram kach na sekundę (pełne obciążenie procesora) przedstaw iony je st na rysunku 5.

D ig italiza cja W y św ietlen ie Proc. 1 „

K o m p re sja W y sła n ie = > P 2

□

i

□

1

□

i 54% 1 1 54% 1 ! 58% 1

1 1 1

P to ę v 2 W y sła n ie(§ ieć) 1 1 1

. . R r « ,J 3 ...0 d W ó r ( 5 ip i ) □ □ □

Proc. 4 0 d b ió r 041 P3 1 1 1

D e k o m p resja 1100% 1 1 100% 1 1 100% 1

Proc. 5 W y św ietlen ie 0 0

D

--- 1--- 1---

--

0 5 0 100 150 2 0 0 2 5 0 3 0 0 3 5 0 4 0 0 4 5 0

Rys. 5. Czasy transm isji i przetw arzania inform acji m ultim edialnej Fig. 5. M ultim edia information transm ission and processing times

Poniew aż procesy s ą podczas pracy w ywłaszczane (co w idać w yraźnie na rysunku 5), pojaw ia się pytanie, ile faktycznie czasu procesora wykorzystują. Pom ocne b ęd ą tu statystyki grom adzone przez jądro system u przy każdym przerw aniu zegarow ym , m ów iące, ile faktycznie czasu proces użytkował procesor oraz ile trw ało w ykonyw anie funkcji system ow ych w yw oływ anych przez ten proces. Procentow e w ykorzystanie czasu wyliczone przy użyciu tych statystyk dla operacji kom presji i dekom presji podano na rysunku.

N ależy zw rócić uwagę, że przedstaw ione wartości są jedynie w artościam i przybliżonymi - statystyki system ow e uaktualniane s ą tylko przy każdym przerw aniu zegarow ym , a więc uzyskana dokładność to co najwyżej 1/100 sekundy. Proces w system ie L inux m oże otrzymać lub utracić procesor nie tylko w wyniku działania standardowej procedury szeregowania wywoływanej przy obsłudze przerw ania zegarow ego, ale także w w yniku wykonywania blokujących operacji we-wy, lub podczas wykonyw ania niektórych funkcji systemowych.

Dlatego też nie m a w iększego sensu obliczanie procentow ego czasu w ykorzystania procesora przy zbyt krótkich operacjach, ja k wysyłanie danych przez sieć czy w yśw ietlanie obrazu, dla których w ynik obarczony je st zbyt dużym błędem - przykładow o dla procesu 3 (odbiór danych z sieci) w ykorzystanie procesora w yliczone z w ykorzystaniem odpow iednich statystyk wynosi 0%.

N ależy zadać tu sobie pytanie, czy poprzez lepsze zarządzanie czasem procesora możliwe je st zm niejszenie opóźnienia spow odowanego przetw arzaniem inform acji m ultim edialnej w systemie. Zw róćm y uw agę, że sam czas przetw arzania danych w system ie przed ich w ysłaniem przez sieć nie je s t optym alny - przy innym dzieleniu procesora m iędzy zadania czas kom presji m ożna byłoby skrócić praw ie o połowę, jeżeli procesor odbierany byłby procesow i pierw szem u dopiero po zakończeniu kom presji. W ten sposób m ożna byłoby uzyskać m niejsze całkow ite opóźnienie transm isji inform acji m ultim edialnej. W ydaje się więc, że aplikacja w spółdziałając z system em operacyjnym przy w ykorzystaniu zasobów (w

Analiza pracy aplikacji m ultim edialnych czasu rzeczyw istego w system ie Linux 141

tym przypadku CPU ) m ogłaby osiągnąć lepsze wyniki, a w ięc zapew nić użytkow nikow i usługi o lepszej jakości.

6. Praca aplikacji w systemie obciążonym innymi procesam i

P rzeprow adzane dotychczas eksperymenty wykonyw ane były w system ie nieobciążonym żadnymi dodatkowym i aplikacjam i użytkownika. Płynność odtw arzania obrazu po zastosow aniu bufora klatek w ideo m ożna śmiało określić ja k o zadow alającą. Jednak trudno w yobrazić sobie, aby kom puter był wykorzystywany stale tylko przez je d n ą aplikację, zwłaszcza w system ie w ielodostępnym , w którym m oże pracow ać na raz wielu użytkowników, a takim system em je st Linux. Dlatego istotne było przebadanie zachow ania się aplikacji m ultim edialnej w obciążonym innymi rów nolegle w ykonywanym i procesam i systemie.

Rysunek 6 przedstaw ia wykresy opóźnienia oraz ilości klatek na sekundę dla trzech przypadków:

a) system nieobciążony dodatkowym i procesami,

b) system obciążony dodatkowo procesem konsum ującym w pętli czas procesora i w yśw ietlającym liczby w oknie term inala,

c) system obciążony dodatkowo procesem konsum ującym w pętli czas procesora oraz pracującym kom pilatorem C.

Param etry pracy podane aplikacji to 10 klatek na sekundę, rozm iar klatki 300x200, 256 odcieni szarości. Czas każdego z rejestrow anych eksperym entów w ynosił 30 sekund. Przy systemie nieobciążonym (rysunek 6.a) aplikacja nie m a żadnych problem ów z zachow aniem płynności w yśw ietlania oraz utrzym aniem żądanych 10 klatek n a sekundę - obciążenie procesora oscyluje w okół 70 %. Jednak w przypadku b) uzyskiw ana ilość klatek na sekundę spada do 4-5, zaś opóźnienie transm isji poszczególnych klatek zw iększa się ponad dwukrotnie, nie m a także m owy o jakiejkolw iek płynności odtw arzania. Jeszcze gorzej wygląda sytuacja w punkcie c) - ilość klatek na sekundę spada do średnio trzech, co oczywiście nie m oże być akceptowalne przez użytkow nika aplikacji.

Rys. 6. O późnienie oraz ilość klatek na sekundę w zależności od obciążenia system u Fig. 6. D elay and frames per second depending from system load

Przy większej ilości procesów pracujących w system ie procesor przydzielany je s t wg standardow ego „spraw iedliw ego” unix’ow ego algorytm u szeregow ania. A lgorytm ten nie jest jed n ak zadow alający dla aplikacji m ultim edialnych. U żytkow nik korzystający z usługi m ultim edialnej czasu rzeczywistego, np. w ideokonferencji oraz z innych aplikacji jednocześnie, chciałby przypuszczalnie m ieć zapew nioną rów nom ierność przesyłania obrazu i dźwięku, w razie konieczności kosztem m niejszej ilości klatek na sekundę czy słabszej jakości obrazu, natom iast inne procesy - nie będące procesam i czasu rzeczyw istego - nie powinny zakłócać pracy w ideokonferencji, naw et kosztem m niejszej własnej w ydajności.

O kazuje się także, że zw iększanie priorytetu aplikacji m ultim edialnej nie przynosi tu oczekiw anych efektów [6). Przy zbyt dużym priorytecie następuje „zagłodzenie” innych

Analiza pracy aplikacji m ultim edialnych czasu rzeczyw istego w system ie Linux 143

procesów, interfejs użytkow nika (myszka, klaw iatura) przestaje praw idłow o reagować. Przy mniejszym priorytecie w ym agania aplikacji nie są spełnione.

7. Analiza strumienia przepływu inform acji multim edialnej

K ażdy etap przetw arzania oraz transm isji inform acji m ożna przestaw ić jako pewien moduł pobierający dane z wejścia, przetw arzający je lub tylko transm itujący, oraz przekazujący przetw orzone dane na wyjście. C ałą drogę, ja k ą przechodzą dane m ultim edialne od m om entu digitalizacji na jednym kom puterze do w yśw ietlenia na drugim , przedstaw ia rysunek 7.

Rys. 7. Strum ień przepływu inform acji m ultim edialnej Fig. 7. M ultim edia inform ation flow stream

Każdy m oduł m ożna scharakteryzować za pom ocą takich param etrów , ja k rozm iar danych wejściowych oraz rozm iar danych wyjściowych (m ogą one różnić się np. w skutek kom presji czy dekom presji), czas (średni, m inim alny, m aksym alny) przetw arzania określonej porcji danych w ejściow ych. Param etry te m ożna łatw o przekształcić w przepustow ość, średnie opóźnienie, w ahania opóźnienia. Innym nie analizow anym tu param etrem je s t w spółczynnik gubienia danych, które m oże w ystępować nie tylko podczas transm isji danych w sieci, ale także w m odułach kom presji i dekom presji, w przypadku niew ystarczającej ich w ydajności.

Każdy m oduł potrzebuje do swojej pracy pew nych zasobów . D la kom presji i dekom presji będzie to przede w szystkim czas procesora, dla w ysyłania i odbierania danych interfejs we- wy sieciow ego, dla transm isji w sieci np. naw iązane połączenie o określonych param etrach w przypadku ATM . W arunkiem przetw orzenia danych przez m oduł je s t w ięc nie tylko pojawienie się odpow iednich danych na jego wejściu, ale rów nież przydzielenie mu w szystkich wym aganych zasobów . Tak w ięc całkow ite opóźnienie pow stające podczas przetw arzania i transm isji danych równe je st sum ie opóźnień pow stających w poszczególnych modułach oraz opóźnień w aktywowaniu odpow iednich m odułów , kiedy na ich wejściu czekają dane, ale nie zostały im jeszcze przydzielone przez system w ym agane zasoby.

W ym usza to na system ie zintegrow ane zarządzanie zasobam i - np. przydział pasm a w sieci wymaga rów nież przydzielenia aplikacji interfejsu w e-w y sieciowego, buforów w pam ięci,

kanału DM A itp., oraz - aby zm inim alizow ać czas przepływ u danych - odpow iednie zasoby pow inny być przydzielane m odułom najpóźniej w m om encie, kiedy na ich w ejściu pojawiają się dane.

8. Proponowane rozszerzenia mechanizmu szeregowania procesów

System operacyjny pow inien oddzielać procesy czasu rzeczyw istego (w przypadku aplikacji m ultim edialnych m ów im y o tzw. „soft realtim e”) od pozostałych oraz zawierać m echanizm y pozw alające im w spółdziałać przy zarządzaniu zasobam i. W wyniku przeprow adzonych badań dla CPU m ożna zaproponow ać w zbogacenie mechanizm u szeregow ania procesów o następujące cechy:

• odróżnienie aplikacji m ultim edialnych czasu rzeczyw istego od pozostałych procesów,

• przechow yw ania przez zarządcę zasobów inform acji o ilości dostępnych w danej chwili zasobów w systemie oraz przydzielanie tych zasobów aplikacjom czasu rzeczyw istego w wyniku przeprowadzonej z nim i negocjacji, co pociąga rów nież za so b ą konieczność opracowania interfejsu negocjacji QoS,

• zapew nienie aplikacjom czasu rzeczyw istego pew nego uzgodnionego (wynegocjow anego przy starcie aplikacji) czasu przydziału procesora (w ogólności rów nież innych zasobów ) niezależnie od obciążenia system u innym i procesam i. Jeżeli nie je st to m ożliw e - kiedy dostępność zasobów w system ie zm ienia się - przeprow adzenie adaptacji aplikacji m ultim edialnych do nowej dostępności zasobów,

• pozostaw ienie aplikacji decyzji o m om encie zw rotu procesora (lub innego zasobu), w ram ach uzgodnionego wcześniej przydziału czasu dla aplikacji,

• udostępnienie m echanizm u okresowego cyklicznego urucham iania procesu,

• aktywow anie kolejnych procesów na ścieżce przepływ u inform acji m ultim edialnej w m om encie, kiedy na ich wejściu pojaw iają się dane, co w ym aga powiązania m echanizm ów kom unikacji z szeregowaniem procesów.

L IT E R A T U R A

1. Karm ański J.: Jakość usług w rozproszonych system ach m ultim edialnych. VI K onferencja Sieci K om puterowych, ZNPS seria Inform atyka z. 36.

2. Hafid A., Bochm ann G.v., D ssouli R.: D istributed m ultim edia A pplications and Q uality o f Service.

Analiza pracy aplikacji m ultim edialnych czasu rzeczyw istego w system ie Linux 145

3. H afid A., B ochm ann G.v.: Som e Principles for Q uality o f Service M anagem ent.

4. W ajda K., B łasiak J., Grzybacz M ., M arek C.: B udow a sieci kom puterow ych w technologii ATM . W ydawnictwo Fundacji Postępu Telekom unikacji, K raków 1997.

5. M allikaijun Tatipamula, Bhum ip Khasnabish: M ultim edia C om m unication Networks:

Technologies and Services. Artech House. Boston, London 1998.

6. Krishnam urthy L.: AQUA: An Adaptive Quality o f Service Architecture for D istributed M ultim edia Applications.

7. Y au D., Lam S.: A n Architecture Towards Efficient OS Support for Distributed Multimedia.

8. Stone D.L., Jeffay K.: An Em pirical Study o f D elay Jitter M anagem ent Polices.

M ultim edia System s, V olum e 2, N um ber 6 (January 1995) pages 267-279.

9. Jeffay K., Stone D.L, Sm ith F.D.: Transport and D isplay M echanism s For M ultim edia Conferencing A cross Packet-Switched Networks.

10. Jeffay K., Bennett D.: A Rate-Based Execution Abstraction For M ultim edia Computing.

11. Hafid A., Bochmann G.v.: An A pproach To Q uality O f Service M anagem ent For D istributed M ultim edia Application.

Recenzent: D r inż. M aciej Bargielski

W płynęło do redakcji 18 listopada 1999 r.

A b stra c t

Im portant area o f research on Q uality o f Service relates to resource allocation w ithin real­

time operating system s in order to be able to guarantee specific perform ance guarantees for real-time processing o f m ultim edia data. In order to m eet the user and application requirem ents operating system have to provide som e m echanism s quality o f service. To find requirem ents o f distributed real-tim e m ultim edia applications program for L inux w as created.

Schem a o f the application is presented on figure 1 and 4, research configuration is presented on figure 2. C hart on figure 3 shows delays before and after adding video frames buffer to tested application.

M ultim edia system s contain a num ber o f stream processing com ponents (figure 7), responsible for video com pression and decom pression, data transm ission etc. The resulting end-to-end quality o f m ultim edia service m ust be considered to be the concatenation o f the QoS characteristics o f the individual transm ission and com puting com ponents through w hich

the inform ation flows. Figure 5 presents delay generated for tested application in every system com ponent.

O ther im portant problem is co-operating real-tim e m ultim edia application w ith others program s w orking in system . Figure 6 presents achieved delays and frames per second in function o f system load.

Finally, som e m ethods o f im proving perform ance o f m ultim edia applications are proposed in point 8. M ost im portant are: special support in operating system for m ultim edia real-tim e applications, QoS negotiation, enforce, adaptation.