oso.com.pl – Michał Matyjek

Kontynuując badanie wpływu różnych czynników na pasmo wykorzystywane przez protokoły zdalnej prezentacji przejdźmy do zbadania wpływu głębi kolorów na interesujące nas wartości.

Środowisko
Znowuż wracamy do środowiska, które opisałem już wcześniej w tym wpisie. Poruszamy się tym razem tylko w obrębie klienta RDP wbudowanego w Windows XP (chodzi o wersję 5.1, na chwilę obecną przez Windows Update dostępna jest od pewnego czasu wersja 6.0).

Pomiary
Tym razem pomiary były dość proste – poszczegĂłlne testy zostały przeprowadzone w 8-bitowej głębi kolorĂłw (wszystkie pozostałe w innych wpisach dotyczą 16-bitowej głębi kolorĂłw czyli tzw. „tysiące”) a następnie porĂłwnane z wynikami przy 16 bitach.

Wyniki
Na początek tabelka – porĂłwnanie:

Tabela 1 Wzrost (na czerwono) lub spadek (na zielono) wykorzystanego pasma w Kbps przy wzroście głębi kolorów z 8 do 16 bitów

I od razu krĂłtkie wyjaśnienie – „Average rate” to średnie wykorzystanie pasma podczas testu. „Peak rate” to maksymalne wykorzystanie pasma podczas testu. Od razu rzuca się w oczy ciekawostka – generalnie wykorzystanie pasma wzrasta wraz ze wzrostem głębi kolorĂłw (logicznie). Jednak w przypadku arkusza kalkulacyjnego i klientĂłw RDP Microsoft (MSTSC) wykorzystanie pasma zmalało. JeĹźeli ktoś potrafi to wytłumaczyć – proszę o sygnał. Ja tłumaczę to sobie optymalizacją klientĂłw Microsoft i Excela pod kątem 16-bitowej głębi kolorĂłw. MoĹźliwe teĹź, Ĺźe wykresy wyświetlane podczas testu są inaczej renderowane i stąd takie zachowanie aplikacji?

Powyższa tabela dotyczy sieci o przepustowości 100Mbps. Jeżeli kogoś interesuje wpływ głębi kolorów na zachowanie klientów przy ograniczonej przepustowości łącza to zapraszam do przejrzenia poniższych wykresów:

Wykres 1 Porównanie czasu wykonywania testu „Edytor tekstu” przez wszystkich przetestowanych klientów RDP w zależności od przepustowości sieci przy 16-bitowej i 8-bitowej głębi kolorów (odpowiednio bez oznaczenia i z oznaczeniem [8bit])

Wykres 2 Porównanie czasu wykonywania testu „Arkusz kalkulacyjny” przez wszystkich przetestowanych klientów RDP w zależności od przepustowości sieci przy 16-bitowej i 8-bitowej głębi kolorów (odpowiednio bez oznaczenia i z oznaczeniem [8bit])

Wykres 3 Porównanie czasu wykonywania testu „Przeglądarka zdjęć” przez wszystkich przetestowanych klientów RDP w zależności od przepustowości sieci przy 16-bitowej i 8-bitowej głębi kolorów (odpowiednio bez oznaczenia i z oznaczeniem [8bit])

Wnioski
Co, moim zdaniem wynika dla nas z powyĹźszych pomiarĂłw?
Po pierwsze – jeĹźeli mamy dużą dostępną przepustowość (56-128Kbps na uĹźytkownika) i aplikację bez większej ilości grafiki – nie musimy się przejmować głębią kolorĂłw. Dopiero jeĹźeli dostępna przepustowość jest problemem (i uĹźytkownikom nie będzie przeszkadzała gorsza jakość obrazu… 😉 ) – obniĹźamy głębię kolorĂłw.
Po drugie – wpływ głębi kolorĂłw na wykorzystanie pasma moĹźe zaleĹźeć od aplikacji i od klienta protokołu (patrz Arkusz kalkulacyjny powyĹźej). Zanim więc przytniemy głębię kolorĂłw warto sprawdzić czy na pewno w ten sposĂłb zaoszczędzimy na wykorzystaniu pasma….

Dziś króciutko o wpływie rozdzielczości w sesji terminalowej na wykorzystanie pasma przez protokół RDP.

Środowisko
Znowuż wracamy do środowiska, które opisałem już wcześniej w tym wpisie. Poruszamy się tym razem tylko w obrębie klienta RDP wbudowanego w Windows XP (chodzi o  wersję 5.1, na chwilę obecną przez Windows Update dostępna jest od pewnego czasu wersja 6.0).

Wyniki
PoniĹźsze wykresy wymagają, moim zdaniem, krĂłtkiego objaśnienia. Starałem się na nich pokazać, jak zmienia się wykorzystanie pasma wraz ze wzrostem rozdzielczości i porĂłwnać je do całkowitej liczby pikseli wyświetlanych w sesji terminalowej. Pomiary wykorzystania pasma i liczbę pikseli na ekranie porĂłwnałem do wartości osiąganych w rozdzielczości 800×600 stąd wszystkie wykresy zaczynają się od wartości 1.
Na wykresach pojawiają się trzy linie:

1. Zielona – wzrost liczby pikseli wyświetlanych w sesji terminalowej
2. Niebieska – maksymalne wykorzystanie pasma podczas testu
3. Granatowa – średnie wykorzystanie pasma podczas testu

Wykres 1 Wzrost wykorzystania pasma wraz z rozdzielczością w przypadku aplikacji zawierającej głównie statyczną grafikę.

Wykres 2 Wzrost wykorzystania pasma wraz z rozdzielczością w przypadku aplikacji wyświetlającej oprócz tekstu pewne elementy graficzne.

Wykres 3 Wzrost wykorzystania pasma wraz z rozdzielczością w przypadku aplikacji wyświetlającej pokaz zdjęć.

Podczas badań mierzyłem też czas wykonania testów. Wyniki w poniższej tabeli:

Tabela 1 Wpływ rozdzielczości na czas wykonania testów.

Wykresy powyĹźej zostały przeliczone odpowiednio przez czas trwania testĂłw, poniewaĹź uznałem, Ĺźe wykorzystany przeze mnie sprzęt mĂłgł mieć wpływ na czas wykonania testĂłw w wyĹźszych rozdzielczościach. Oczywiście mogę się mylić i wolniejsze przetwarzanie grafiki przy wyĹźszych rozdzielczościach, widocznie szczegĂłlnie w teście „przeglądarka zdjęć”, jest niezaleĹźne od mocy procesora czy ilości pamięci.

Podsumowanie
Nie wiem, czy moje wnioski są trafne, ale z analizy wynika, że protokół RDP dobrze radzi sobie z podwyższaniem rozdzielczości. Większa ilość pikseli, które serwer przesyła do klienta, nie wpływa znacznie na wykorzystanie łącza. Nawet w przypadku aplikacji o dużej ilości zmiennej grafiki (przeglądarka zdjęć) wykorzystanie pasma rosło wolniej niż teoretyczna ilość pikseli wyświetlanych na ekranie.
Warty odnotowania jest na pewno zdecydowanie dłuĹźszy czas trwania testĂłw. Wyświetlenie po stronie klienta tej samej ilości tych samych zdjęć trwało prawie dwukrotnie dłuĹźej przy rozdzielczości 1280×1024 niĹź przy 800×600. W przypadku aplikacji zawierających mniejszą ilość grafiki czas ten wzrasta minimalnie.
Możliwe, że na dłuższy czas wyświetlania miał wpływ używany przeze mnie podczas testów sprzęt, dlatego obliczenia dotyczące średniego i maksymalnego wykorzystania pasma uwzględniły różnice w czasie.

Kompresja w protokole RDP
Architektura protokołu RDP (jak i innych protokołów wykorzystywanych w konkurencyjnych usługach centralnego przetwarzania) umożliwia włączenie bądź wyłączenie kompresji.
W przypadku klienta RDP wbudowanego w systemy operacyjne Microsoft (mstsc.exe) nie mamy możliwości zmiany tego ustawienia z interfejsu graficznego klienta. W przypadku klienta RDP dostarczanego z systemem Windows NT TSE kompresja była domyślnie wyłączona. Od Windows 2000 wzwyż opcja ta jest domyślnie włączona a wyłączyć ją można wpisując 0 zamiast 1 w linii:
compression:i:1
w pliku .rdp opisującym dane połączenie.

Kompresja RDP a obciążenie procesora
Na początku trzeba podkreślić, Ĺźe dodatkowe obciążenie procesora związane z włączeniem kompresji w protokole RDP 5.0 jest minimalne. Wszelkie obawy administratorĂłw powinien rozwiać artykuł opublikowany przez Microsoft: „Remote Desktop Protocol (RDP) Features and Performance”.

Kompresja RDP a wykorzystanie sieci
Skoro już wiemy, że kompresja nie obciąży zbytnio CPU zastanówmy się, co możemy dzięki niej zyskać.
OdpowiedĹş jest oczywista – niĹźsze wykorzystanie sieci. O ile niĹźsze? Na poniĹźszych wykresach znajduje się odpowiedĹş.
Dodam tylko, że środowisko testowe i pomiary są identyczne jak w tym wpisie i do niego proszę zajrzeć po szczegóły. W pomiarach wykorzystanych przy tworzeniu poniższych wykresów korzystałem z klienta rdesktop 1.4.1 uruchomionego na maszynie z systemem Fedora Core 5.

Wykres 1 Porównanie wykorzystanego podczas testu „Edytor tekstu” pasma w zależności od kompresji, protokół RDP, klient rdesktop 1.4.1

Wykres 2 Porównanie czasu wykonywania testu „Edytor tekstu” w zależności od przepustowości sieci przy włączonej i wyłączonej kompresji, protokół RDP, klient rdesktop 1.4.1

Wykres 3 Porównanie wykorzystanego podczas testu „Arkusz kalkulacyjny” pasma w zależności od kompresji, protokół RDP, klient rdesktop 1.4.1

Wykres 4 Porównanie czasu wykonywania testu „Arkusz kalkulacyjny” w zależności od przepustowości sieci przy włączonej i wyłączonej kompresji, protokół RDP, klient rdesktop 1.4.1

Wykres 5 Porównanie wykorzystanego podczas testu „Przeglądarka zdjęć” pasma w zależności od kompresji, protokół RDP, klient rdesktop 1.4.1

Wykres 6 Porównanie czasu wykonywania testu „Przeglądarka zdjęć” w zależności od przepustowości sieci przy włączonej i wyłączonej kompresji, protokół RDP, klient rdesktop 1.4.1

Podsumowanie
Jak wynika z przedstawionych powyĹźej wynikĂłw, kompresja RDP w znaczny sposĂłb wpływa na wykorzystanie sieci. Największą róşnicę widzimy przy aplikacjach zawierających małą ilość grafiki jak edytor tekstu czy arkusz kalkulacyjny – w tych dwĂłch wypadkach wykorzystanie pasma było średnio około 3 razy większe jeĹźeli kompresja została wyłączona.
Jeszcze lepiej pokazuje wpływ kompresji wykres przedstawiający czas wykonania testĂłw – szczegĂłlnie w przypadku edytora tekstu i dostępnego pasma poniĹźej 128Kbps.
Jednocześnie widać, Ĺźe nawet aplikacje zawierające dużą ilość skomplikowanej grafiki, dają się „kompresować” i dzięki temu zmniejsza się wykorzystanie naszej sieci a co za tym idzie poprawia się jakość pracy klientĂłw pracujących zdalnie.
Przy okazji odsyłam do porĂłwnania klientĂłw RDP  – opisywany w tym wpisie klient RDP: tsclient ma wyłączoną domyślnie kompresję RDP (i nie moĹźna jej włączyć). Czarno na białym widać na wykresach, jaki wpływ na komfort pracy ma takie a nie inne ustawienie tego klienta. Wszystkim pracującym z tsclient jeszcze raz gorąco polecam przejście na rdesktop.

KrĂłtko o RDP
Protokół Remote Desktop Protocol został opracowany jako zastępnik ICA w systemie Windows NT 4.0 TSE oraz późniejszych. Microsoft uzyskał od firmy Citrix Systems technologię umożliwiającą jednoczesną pracę zdalną wielu użytkowników naraz jednak sam protokół ICA pozostał własnością firmy Citrix.

Wersja 4.0 była bardzo mało wydajna i nadawała się do pracy wyłącznie w sieciach LAN. Wraz z wprowadzeniem na rynek systemu Windows 2000 pojawiła się wersja 5.0 protokołu RDP, która znacząco poprawiła wydajność jednak nadal pozostawała w tyle za ICA – RDP 5.0 potrzebował większej przepustowości i umożliwiał wyświetlanie maksymalnie 256 kolorów. Od wersji 2000 serwerów Microsoft serwery terminalowe (umożliwiające zdalną pracę użytkowników) nie są oddzielną wersją serwera ani nie wymagają żadnego specjalnego oprogramowania. Wraz z licencją serwera dostarczana jest licencja na administracyjne (maksymalnie 2 jednocześnie) zdalne sesje. Zamiana serwera w pełny serwer terminalowy polega jedynie na doinstalowaniu odpowiedniego komponentu i dołączeniu licencji.

Pojawienie się Windows 2003 Server połączone zostało z wprowadzeniem wersji 5.1 a następnie 5.2 protokołu RDP. Wraz z wprowadzeniem serwera „Longhorn” (następca Windows 2003 Server) pojawi się RDP w wersji 6.0 (więcej o tej wersji w Wikipedii). Od wersji 5.1 RDP wspiera 24-bitowy kolor oraz przesyłanie dĹşwięku od serwera do klienta (w drugą stronę nie jest to moĹźliwe). Pomimo znacznie poprawionej wydajności RDP 5.2 ma gorszą wydajność niĹź ICA (ok. 20-25Kbs vs. 5-20Kbps w ICA) oraz mniejszą funkcjonalność (brak wsparcia dla technologii seamless windows – pojawi się dopiero w RDP 6, ograniczone moĹźliwości multimedialne i przekierowania portĂłw).
RDP wykorzystuje port 3389/TCP.

Przetestowane oprogramowanie
Podczas testów tego protokołu użyłem następujących klientów:
• Microsoft Terminal Services Client 5.1 – domyślnie dostarczany z Windows XP
• Microsoft Terminal Services Client 5.2 – domyślnie dostarczany z Windows 2003
• rdesktop 1.4.1 – klient RDP pod platformy *nixowe, strona domowa
• tsclient 0.140 – graficzna nakładka na rdesktop, strona domowa
W praktyce korzysta się z różnych wersji klienta RDP w zależności od systemu, który zainstalowany jest po stronie użytkownika. Jeżeli systemem tym będzie Windows XP korzysta się z wbudowanego klienta MSTSC 5.1, ale na tym samym systemie operacyjnym można niezależnie zainstalować inne wersje tego klienta RDP – np. MSTSC 5.2. Jeżeli systemem operacyjnym po stronie klienta będzie Linux lub Unix to korzysta się z jednego z klientów RDP pod te systemy – np. rdesktop czy tsclient.
Tsclient jest w zasadzie tylko nakładką graficzną na rdesktop. Ponieważ jednak wielu użytkowników korzysta z niego nie wiedząc nic o rdesktop, został przetestowany oddzielnie. 

Środowisko testowe
Microsoft Windows 2003 Server R2 z włączonymi usługami terminalowymi w trybie aplikacji, zainstalowany na maszynie wirtualnej działającej pod kontrolą VMware Server 1.0 na Fedora Core 5. Po stronie klienta był Windows XP Professional SP2 Polski (mstsc 5.1, mstsc 5.2) lub Fedora Core 5 (rdesktop i tsclient).

Przetestowane aplikacje
Wykonane przy pomocy AutoIT skrypty automatycznie wykonywały takie same polecenia w przypadku testów każdego z klientów. Przetestowane aplikacje to:
• edytor tekstĂłw – Microsoft Word XP, podczas testu wpisywany był kilkustronicowy tekst, test odzwierciedla aplikację z małą ilością grafiki
• arkusz kalkulacyjny – Microsoft Excel XP, arkusz wypełniany był losowymi wartościami na podstawie ktĂłrych generowane było kilkanaście róşnych wykresĂłw, test odzwierciedla pracę z aplikacją zawierającą pewną ilość grafiki (np. przeglądanie stron WWW)
• przeglądarka zdjęć – podgląd obrazĂłw i faksĂłw w Windows 2003 Server, kilkanaście zdjęć o róşnej jakości przeglądane na całym ekranie, test odzwierciedla pracę z aplikacją o duĹźej ilości grafiki

Pomiary
W przypadku pomiaru wykorzystania pasma pomiar dokonywany był na wirtualnym interfejsie VMware za pomocą iptraf, klienci mieli dostępną całą przepustowość sieci 100Mbit.
W przypadku pomiaru czasu wykonania testu dostępne pasmo ograniczane było przy pomocy narzędzia tc z pakietu iproute a czas wykonania testu mierzyły same skrypty AutoIT.

Interpretacja
Pomiar wykorzystanego pasma podczas pracy w sieci 100Mbit pokazuje jaka jest teoretycznie wymagana przepustowość do pracy z danym klientem i aplikacją. Przepustowość zalecana odpowiada średniemu wykorzystania pasma podczas testu. Przepustowość komfortowa jest równa maksymalnemu wykorzystaniu pasma podczas testu.
Udostępniając klientowi pasmo większe niż przepustowość komfortowa mamy pewność, że zapobiegniemy stratom jakości czy czasu podczas pracy zdalnej. Udostępniając pasmo większe niż przepustowość zalecana możemy spodziewać się pewnych niedogodności (obniżenie jakości, opóźnienia) jednak nadal praca powinna być możliwa. Jeżeli dostępne pasmo spadnie poniżej wartości zalecanej możemy spodziewać sie dużych opóźnień w pracy.

Tabela 1 Wyniki pomiaru wykorzystanego pasma przy sieci 100Mbps dla protokołu RDP i wszystkich przetestowanych klientów RDP. Najlepszy wynik w danej kategorii – tło zielone, najgorszy – tło czerwone.

Pomiar czasu wykonywania testu odzwierciedla rzeczywisty wpływ dostępnego pasma na czas wykonania identycznych czynności w danych aplikacjach. Wartość 100 określa czas wykonania testu w sieci o przepustowości 100Mbit.

Wykres 1 Porównanie czasu wykonywania testu „Edytor tekstu” przez wszystkich przetestowanych klientów protokołu RDP w zależności od przepustowości sieci

Wykres 2 Porównanie czasu wykonywania testu „Arkusz kalkulacyjny” przez wszystkich przetestowanych klientów protokołu RDP w zależności od przepustowości sieci

Wykres 3 Porównanie czasu wykonywania testu „Przeglądarka zdjęć” przez wszystkich przetestowanych klientów protokołu RDP w zależności od przepustowości sieci

Analiza wynikĂłw
Warto na początku podkreślić znaczne róşnice w wydajności pomiędzy tsclient a rdesktop. Tsclient wymaga przeciętnie dwa razy większej przepustowości od rdesktop. Przekłada się to na wyniki przy ograniczonej przepustowości – w przypadku edytora tekstu i dostępnej przepustowości na poziomie 128Kbps róşnica jest niezauwaĹźalna. Przy mniejszych przepustowościach robi się znaczna. Róşnice te wynikają z faktu, Ĺźe rdesktop nie ma domyślnie włączonej kompresji (więcej o wpływie kompresji na wydajność – wkrĂłtce) a tsclient po prostu nie oferuje moĹźliwości jej włączenia. W naszych testach kompresja w przypadku klientĂłw Microsoftu i rdesktop była włączona.
Jeżeli używacie więc tsclient polecam przejście na rdesktop (chyba, że nie możecie żyć bez graficznej nakładki).
Róşnice między mstsc 5.1 a 5.2 są w zasadzie Ĺźadne. Najciekawszy, moim zdaniem, jest fakt, Ĺźe w testach aplikacji zawierających większą ilość grafiki najlepiej wypadł rdesktop – niezaleĹźna od Microsoft aplikacja.