Resultater

Ytelsesmålinger over TCP

Det var ønskelig å prøve ut ytelsen over TCP med hensyn på en del forskjellige parametre. Først og fremst var det interessant å variere antall linker, for å se hvordan ytelsen økte med antall telefoner i bruk. Dernest var det interessant å se hvordan ytelsen varierte med varierende mottaksforhold for mobiltelefonene. Det var også ønskelig å prøve både ikke-transparent og transparent overføring. Det var ønskelig å prøve ut overføring av forskjellige typer filer for å undersøke hvordan komprimering kan virke inn på overføringen. Og sist men ikke minst var det ønskelig å variere pakkestørrelsene for å se om dette hadde noen innvirkning på kommunikasjonen. I alle testene som ble utført, ble størrelsen til TCP-bufferet satt til 8192.

Sammenlikning av ytelse i forhold til antall linker.

Det ble gjort noen prøver for å prøve ut hvordan forskjellige antall linker virket inn på ytelsen på kommunikasjonen. Det ble overført både lett komprimerbare (vanlig bruk av ttcp), og vanskelig komprimerbare (overføring av /usr/bin/zcat ) filer. Resultatene er presentert i tabell og figur . I disse prøvene var MRU satt til 1500 og MRRU satt til 1600. Signalforholdene var bra under disse prøvene, og overføringen ble utført i ikke-transparent modus. Tallene i tabellen er middel over prøvene som ble gjort.

 

1 mobil 2 mobiler 4 mobiler 1 vanlig modem

lett komprimerbar fil 0.74 2.60 4.45 5.14

ikke komprimerbar fil 0.80 2.06 4.14 3.45

 

Figure:  Sammeligning av TCP-ytelse

Resultatene kan i første omgang synes nokså merkverdige, særlig hoppet fra resultatet for 1 mobiltelefon til resultatet for 2 mobiltelefoner som innebærer over en tredobling i ytelse. Dette hoppet skyldes antakelig at TCP sin algoritme for Congestion-Avoidance (se ) slår til for fullt når kapasiteten er så lav som den er med bare en mobiltelefon. På grunn av dette blir ikke linkens kapasitet utnyttet godt nok. Det blir den derimot når kapasiteten økes til 2 eller flere telefoner, og vi ser et hopp i ytelse. Filstørrelsene som ble overført (65536 for den lett kompimerbare filen og 90112 for den ikke-komprimerbare) er typiske filstørrelser i Internett-bruk og denne ytelsesvurderingen er derfor realistisk. Forskjellen i filstørrelse kan også forklare hvorfor den ikke-komprimerbare filen gav bedre ytelse på linken med bare en mobiltelefon.

For lett komprimerbare filer ser vi at ytelsen til 4 mobiltelefoner ligger et stykke under ytelsen til et vanlig 28.8 kbps modem. For ikke-komprimerbare filer forandrer dette seg. Årsaken er at 28.8 modemet implementerer gode komprimeringsprotokoller (for eksempel v42bis), mens mobiltelefonene ikke støtter dette. Imidlertid observerer vi også en forskjell på lett-komprimerbare og ikke-komprimerbare filer på mobiltelefonene. Denne effekten skyldes trolig den enkle komprimeringen som er implementert i RLP-protokollen som brukes ved ikke-transparent overføring (se ).

Sammenligning av ytelse i forhold til pakkestørrelser

For å undersøke om pakkestørrelsene var relevant for ytelsen på overføringen ble det gjort en del forsøk med forskjellige pakkestørrelser. Pakkestørrelsene ble endret ved å sette MRU og MRRU (se ) i begge ender. Igjen ble det benyttet transparent overføring med TCP-buffer 8192 under gode signalforhold. Tallene i tabellen er et middel over resultatene vi fikk.

 

1 mobil 1 mobil 4 mobiler 4 mobiler

komprimerbar ikke komprimerbar komprimerbar ikke-komprimerbar

MRU=1500, MRRU=1600 0.74 0.80 4.45 4.14

MRU=750, MRRU=1600 0.77 0.80 ikke målt 4.14

MRU=325, MRRU=1600 0.77 0.67 ikke mulig ikke mulig

MRU=1500, MRRU=3200 ikke målt ikke målt 4.40 4.13

MRU=1500, MRRU=6400 ikke målt ikke målt 4.35 4.14

MRU=1500, MRRU=750 ikke mulig ikke mulig ikke mulig ikke mulig

MRU=650, MRRU=750 ikke målt ikke målt 4.19 3.97

MRU=225, MRRU=325 ikke målt ikke målt 3.73 3.68

Definisjonene sier at MRU er pakkestørrelse per link, og MRRU er den totale størrelsen på pakkene som går over alle linkene. Av resultatene kan det først sees en del tilfeller som ikke støttes av mpd. I tilfellet med MRU=325 og MRRU=1600 kom det en feilmelding for hver pakke som ble forsøkt sendt, der mpd klaget over at hver linkpakke var større enn MRU tillot. Fremtidige versjoner av mpd bør kunne ta hensyn til dette i forhandlingen av pakkestørrelsene. I tilfellet med MRU=1500 og MRRU=750, nektet mpd på den andre siden å godta denne konfigurasjonen. Det burde være fullt mulig med slike konfigurasjoner, men det ser altså ut til at implementasjonen ikke støtter det.

Når det gjelder resultatene for 1 mobiltelefon ble det observert relativt like resultater for de forskjellige pakkestørrelsene. Teoretisk skulle ytelsen gå noe ned med lavere pakkestørrelser fordi mengden overhead øker. Dette gjelder når det er lite tap på overføringen, som her (ikke-transparent overføring ble brukt). At ytelsen er relativt lik kan forklares med at TCP får mindre problemer når pakkestørrelsen er lavere. For videre behandling av ulike pakkestørrelser over en enkelt mobiltelefon, henvises det til [31].

Resultatene for fire mobillinker viser en del interessante egenskaper. Implementasjonen tillot som nevnt ikke å presse MRU lavere enn en fjerdedel av MRRU. Det ble derfor ikke gjort noen målinger med lav MRU og høy MRRU. Imidlertid ble det gjort målinger med lav MRU og MRRU. I teorien skal slike små pakkestørrelser gjøre ytelsen dårligere fordi mengden overhead øker med større antall pakker. Det er lett å se på resultatene at denne teorien stemmer i praksis. For transparente forbindelser vil saken sannsynligvis bli en annen, da støy vil medføre pakketap og retransmisjoner. Ytelsen vil da sannsynligvis bli bedre med en lavere pakkestørrelse. Det ble også gjort forsøk med høyere verdier for MRRU. I dette tilfellet viste det seg at ytelsen gikk litt ned. Det er ikke helt klart hva denne effekten skyldes.

Forsøk med transparent kommunikasjon

Det ble forsøkt å opprette en kommunikasjonskanal med transparent kanal. Forsøket lykkes ikke. En rekke forskjellige konfigurasjoner ble utprøvet, men ikke i noen av tilfellene lykkes det for LCP å opprette en PPP forbindelse. Ut fra det som kunne leses i loggen kunne det virke som om konfigurasjonspakkene ikke nådde frem til den andre enden, slik at det ikke var mulig å forhandle frem parametrene for forbindelsen. Dette kan skyldes støy i transmisjonen.

Imidlertid fant Tangen i [31] at det både under gode og dårlige transmisjonsforhold var bedre ytelse med ikke-transparent kommunikasjon ved lik hastighet. Dette på grunn av den underliggende RLP-protokollen. Det er ikke noen grunn til å tro at dette vil forholde seg anderledes ved kommunikasjon over flere GSM-kanaler. Dersom fremtidige GSM-nett og termineringsutstyr implementerer GSM gruppe 7 med 12 kbps dataoverføring, er det mulig at det igjen blir interessant å se på TCP/IP over transparente GSM-kanaler.

Forsinkelse

Forsinkelse under stabile forhold

Forsinkelsen på linken ble målt med verktøyet ping. Forsinkelsen er viktig å ha kjennskap til fordi den har stor betydning for for eksempel oppsett og nedkobling av TCP-forbindelser (3-way handshake). Ved trafikktyper som innebærer mange korte TCP forbindelser, som for eksempel WWW-trafikk, vil forsinkelsen på linken på signifikant betydning. I tabell er resultatene fra forsinkelsesmålingene listet opp. Disse målingene ble utført under gode signalforhold.

 

Maks RTT Min RTT Gjennomsnittlig RTT

vanlig modem 1250 170 224

1 mobil 850 829 840

4 mobiler 2061 661 729

Av størst interesse her er nok den gjennomsnittlige verdien, hvor det umiddelbart kan sees at mobillinkene har betraktelig større forsinkelse enn en vanlig modemforbindelse. Dette skyldes hovedsaklig måten foldingskodingen i GSM virker på (se avsnitt ). I tillegg kommer at RLP protokollen som brukes ved ikke-transparent kommunikasjon gir ekstra forsinkelse. Forskjellen i forsinkelse mellom transparent og ikke-transparent kommunikasjon (uten eller med RLP) er godt dokumentert i [31]. Forskjellen i gjennomsnittstid mellom 1 mobillink og 4 mobillinker skyldes at ping-pakkene har blitt spredd på flere kanaler og dermed blitt overført raskere. Den ideelle responstiden (responstiden på en uendelig liten pakke) skal være den samme for fire mobillinker som for 1.

Det ble også observert en større spredning i forsinkelsestidene for fire mobillinker enn for en mobillink. Dette kan ha sin årsak i at sannsynligheten for en feil i radiooverføringen er lik for de fire kanalene. En feil i radiooverføringen vil føre til en korreksjon på RLP-nivå, og dermed en større forsinkelse på den aktuelle kanalen. Siden datagrammet ikke kan bli satt sammen igjen før alle fragmentene har ankommet blir responstiden for hele datagrammet lik den for den dårligste linken. Med lik sannsynlighet for radiofeil på de fire linkene, blir sannsynligheten for forsinkelser på den totale linken fire ganger så stor.

Forsinkelse under ustabile forhold

Det ble også gjort noen målinger av forsinkelse under ustabile forhold. Tabell oppsummerer resultatene her.

 

Maks RTT Min RTT Gjennomsnittlig RTT

1 mobil 1719 810 863

4 mobiler 12890 680 3978

Vi ser at gjennomsnittlig RTT på denne målingen ble høyere for 4 mobiler enn for 1 mobil. Dette stemmer med at den totale forsinkelsen for ett datagram blir like stor som den største forsinkelsen på linkene, som nevnt over. Maks RTT i tabellen over ble meget lang. Dette skyldes at forbindelsen på en av mobilene datt ut i en liten periode under målingen.

I en annen forsinkelsesmåling som ble foretatt startet målingen i et område med god dekning, for deretter å gå inn i et område uten dekning. Utskriften fra denne ping-sesjonen er vedlagt i vedlegg . Dette resultatet viser at forsinkelsen raskt går høyt opp fra normale verdier til svært høye verdier (over 10 sekunder) når signalet blir dårlig. I dette konkrete tilfellet forsvant dekningen helt, og en av telefonsamtalene ble brutt. Fordi signalet var så dårlig klarte ikke mpd å reforhandle den totale linken med den andre siden, og resultatet ble totalt pakketap, som kan sees på utskriften.

Ytelse på WWW

For å få et inntrykk av ytelsen en bruker vil oppleve ble det gjort noen målinger med å hente ned en webside med Netscape. Det ble tatt tiden med stoppeklokke fra brukeren startet forespørselen til hele siden inkludert all grafikk var ferdig nedlastet. Testen ble gjort under gode signalforhold. Resultatene er gjengitt i tabellene under.

 

1 mobil 2 mobiler 3 mobiler 4 mobiler 1 vanlig modem

53.29 s 29.05s 15.95s 11.45s 8.71s

 

1 mobil 4 mobiler 1 vanlig modem

1.17.14 16.40 23.01

Først er det interessant å se hvordan nedlastningstiden synker drastisk med antall telefonlinker ved nedhentingen av http://www.stud.ntnu.no/. Den drastisk økede ytelsen her skyldes sannsynligvis noe av den samme effekten som ble funnet i målingene med ttcp. Dernest kan det slås fast at ytelsen på fire mobillinker i forhold til et vanlig modem varierer med hva slags websider som hentes ned. Det ble lagt vekt på å utføre prøvene flere ganger, og det kan slås fast at variasjonene ikke skyldes tilfeldige variasjoner. Det er heller nærliggende å tro at variasjonene skyldes måten Netscape og TCP oppfører seg på. For prøve ut dette ble det laget tre WWW-sider med forskjellige karakteristikker. Det ble laget en med ett stort bilde, en med mange store bilder og en med mange små bilder. Resultatene er gjengitt under. Sidene er tilgjengelige på adressene som er nevnt i tabellteksten.

 

4 mobiler 1 vanlig modem

17.48 28.39

 

4 mobiler 1 vanlig modem

1.32.84 1.18.40

 

4 mobiler 1 vanlig modem

11.57s 7.76s

Det er helt klart at ved nedhenting av ett stort bilde ble ytelsen på mobillinkene best. Dette er logisk, for når siden kun inneholder et bilde vil nedlastingen kun bestå av en lang TCP-forbindelse. Med en slik karakteristikk vil mobiltelefonene som har større båndbredde enn modemet gi bra ytelse. Slike websider vil svare ganske godt til de resultatene som fremkom ved bruk av ttcp som måleverktøy.

Motsatt gjelder når siden består av mange bilder. Gjentatt oppstart og avslutning av TCP-forbindelser vil da medføre at mobillinkens lange forsinkelse kommer inn i bildet. På slike web-sider vil nedlastningstiden bli lengre med fire mobiltelefoner enn med ett vanlig modem.