Relazione d Internato di Laboratorio di Ingegneria Informatica

Transcript

1 Dipartimento di Ingegneria dell'informazione Relazione d Internato di Laboratorio di Ingegneria Informatica Prestazioni di una rete WiFi b Bergamini Rinaldo, Bompani Stefano

2 Indice Test effettuati con Qcheck 3 Test di Streaming e trasferimento bulk FTP (su protocollo TCP) 8 Test di Streaming e traffico sintetico UDP (generato con Iperf) 19 Test di Streaming Multiplo e traffico sintetico UDP..29 Conclusioni

3 Test effettuati con Qcheck Qcheck è un programma freeware (è richiesta la registrazione dei propri dati) che consente di misurare tempi di risposta e throughput di una rete, oltre alla possibiltà di effettuare test di streaming e di tracciamento dei pacchetti fino a destinazione. Qcheck lo trovate a questo indirizzo: Configurazione: 1 notebook (s.o. Windows XP) collegato all'access Point (AP) tramite scheda di rete Cisco; 1 notebook (s.o. Windows XP) collegato alla LAN con scheda di rete Realtek 8139 Fast Ethernet; Endpoint 1 Il notebook collegato all'ap è stato collocato in ambiente esterno, a circa 60 metri in linea d'aria dall'ap stesso. Eventuali ostacoli presenti: automobili, persone e muri. Endpoint 2 L'altro notebook è stato collocato nel laboratorio Media Room connesso ad un hub, da questo allo switch del laboratorio, quindi allo switch del piano terra della Palazzina 1. Condizioni climatiche: nubi temporalesche con improvvise raffiche di vento, anche di una certa intensità. Modalità: sono state effettuate tre prove per ciascun tipo di test effettuabile con Qcheck, per i parametri utilizzati vedere le singole sezioni

4 INTRODUZIONE COME Qcheck EFFETTUA I TEST Qcheck è un'utility free composta da due software: una console ad interfaccia grafica e un agente software distribuito. Tramite la console è possibile scegliere, ed eseguire, quali test effettuare, mentre gli Endpoint sono dei servizi, eseguiti in background sulle macchine coinvolte nel testing della rete, che si scambiano dati ed inviano il risultato dei test alla console. 1.Response Time Questo test misura quanto tempo occorre per mandare un messaggio di richiesta (request) e ricevere una risposta (reply). Qcheck (tramite console) istruisce l'endpoint 1 affinchè spedisca un blocco di dati all'endpoint 2, che a sua volta spedirà una risposta all'endpoint 1. Il response time è il tempo impiegato per compiere tutta la transazione. Nel dettaglio, il response time è calcolato come: RT = (m mn) / N dove: RT = Response Time N = numero di iterazioni scelte m = tempo misurato (istante finale istante iniziale) 1.a TCP Parametri scelti: Protocollo: TCP Iterazioni: 5 Data Size: 1000 bytes Risultati: RT minimo RT massimo RT medio 1 Run 5 ms 14 ms 8 ms 2 Run 5 ms 5 ms 5 ms 3 Run 5 ms 5 ms 5 ms - 4 -

5 1.a UDP Parametri scelti: Protocollo: UDP Iterazioni: 5 Data Size: 1000 bytes Risultati: RT minimo RT massimo RT medio 1 Run 6 ms 6 ms 6 ms 2 Run 6 ms 7 ms 6 ms 3 Run 5 ms 5 ms 5 ms 2.Throughput Questo test misura il bit rate massimo ottenibile tra due endpoint; i risultati sono funzione anche della dimensione scelta dei dati da inviare (range da 1Kb a 1Mb). L'endpoint 1 spedisce i dati secondo la dimensione scelta dall'utente, e aspetta dall'endpoint 2 una risposta della dimensione fissa di 1 byte. Il throughput (espresso in bit per secondo) è calcolato come il totale dei dati inviati e ricevuti diviso per il tempo totale della transazione: T = (S + R) / m dove: T = throughput rate S = byte spediti dall'endpoint 1 R = byte ricevuti dall'endpoint 1 (fisso, 1 byte) m = tempo totale della transazione Ovviamente valori più alti del throughput implicano prestazioni migliori. 2.a TCP Parametri scelti: Protocollo: TCP Data Size: 1 Mb - 5 -

6 Risultati: THROUGHPUT 1 Run 4,188 Mbps 2 Run 4,103 Mbps 3 Run 4,014 Mbps 2.a UDP Parametri scelti: Protocollo: UDP Data Size: 1 Mb Risultati: THROUGHPUT 1 Run 3,599 Mbps 2 Run 3,587 Mbps 3 Run 3,596 Mbps 3.Streaming Performance Questo test misura la percentuale di dati persi durante una trasmissione di acchetti tramite protocollo UDP. I dati persi sono quelli che non vengono ricevuti dall'endpoint 2 oppure che sono consegnati out of order. Il bitrate scelto per spedire i dati varia da 1 kbps a 1 Mbps, in un intervallo di tempo selezionabile tra i 5 e i 30 secondi. L = ((S R) / S) * 100 dove: L = percentuale di dati persi S = byte totali spediti dall'endpoint 1 R = byte totali ricevuti dall'endpoint 2 Il test restituisce inoltre il troughput verificato dall'endpoint 2 (ricevente) rispetto a quello nominale

7 Risultati: % DATA LOST TROUGHPUT 1 Run 0,00% 958,068 kbps 2 Run 0,00% 794,941 kbps 3 Run 0,00% 953,501 kbps CONCLUSIONI Il risultato più sorprendente è sicuramente quello relativo allo streaming UDP, dove su tre tentativi non risulta perso nessun pacchetto. Per quanto riguarda la banda effettivamente sfruttata, questa si è assestata sui 4 Mbps, ovvero poco più del 36% della banda teorica per il test effettuato con il protocollo TCP, e sui 3,6 Mbps (33% circa) per il test effettuato con il protocollo UDP. Anche qui il risultato è quanto meno anomalo, dal momento che il maggior overhead introdotto dal TCP dovrebbe risultare in un minore utilizzo di banda rispetto all'udp

8 Test di Streaming e trasferimento bulk FTP (su protocollo TCP) Condizioni dell esperimento Questa serie di test è stata effettuata avendo a disposizione due portatili. Uno (bigticket) impegnato ad effettuare un trasferimento ftp bulk da Otello.ce.unipr.it del file reti.tar presente nel direttorio /var/tmp/solutori. La scelta è dovuta alla dimensione del file elevata (850Mb circa), in modo da garantire una certa durata all esperimento. Il server Otello garantirebbe un bitrate sufficiente a saturare la banda teorica di un client Wi-Fi associato ad un AP in condizioni ottimali. Nel contempo, twm ha effettuato uno streaming di un file video MPEG-4 con il player RealOne. Il file è accessibile tramite protocollo RTSP sul server Darwin pp4 (rtsp://pp4/war3_gameplay_ects_2001.mp4). La prova è stata svolta in condizioni differenti di qualità del collegamento: 1. Condizioni Eccellenti: i due host a pochi metri di distanza dall AP e senza ostacoli rilevanti (laboratorio Workstations)

9 Condizioni Buone: all esterno del corridoio della palazzina 1, a circa 20 metri dall AP. Un ostacolo rilevante è risultato essere la porta d accesso alla palazzina stessa: ne è conseguita una qualità del segnale media, come rilevato dall utility Cisco ACU. La banda nominale è comunque rimasta a 11 Mbps.

10 3. Condizioni Sufficienti (fair): all esterno della sede scientifica, in prossimità della palazzina 1. E stato difficile trovare una posizione che garantisse un associazione stabile allo stesso AP per le due macchine. 4. Condizioni scadenti: non è stato possibile ottenere risultati minimamente affidabili a causa delle continue disassociazioni con gli AP. Prova 1 La prima delle prove effettuate in condizioni eccellenti ha coinvolto semplicemente uno streaming del file sopra citato

11 Il bit rate massimo che si raggiunge durante la bufferizzazione è di circa 1,6 Mbps ma siamo interessati soprattutto al valore medio della larghezza di banda (675 Kbps). Utilizzeremo questo valore come teorico, per vedere il degrado di prestazioni aggiungendo traffico sull AP o peggiorando le condizioni del segnale. Effettuando una prova con il solo trasferimento ftp attivo, si sono registrate elevate prestazioni (7,12 Mbps al momento del rilevamento): I grafici sottostanti riportano invece i risultati ottenuti con uno streaming e un trasferimento ftp contemporanei:

12 Come si può notare, lo streaming non viene particolarmente influenzato in tali condizioni: si registra infatti una larghezza di banda finale media di 696,5 Kbps, paragonabile a quella ottenuta nel caso del solo streaming attivo. La stesso non si può dire per il trasferimento ftp: si è notato infatti un degrado delle prestazioni (da 7,12 Mbps a 5,08 Mbps). Resta comunque notevole la banda utilizzata in queste condizioni. Durante la prima prova sono stati effettuati in contemporanea anche due streaming video e un trasferimento ftp. Dal grafico sottostante, preso dalle statistiche di riproduzione di RealOne, si evincono alcuni risultati (capture da twm): il file è codificato a 568 Kbps, mentre la banda utilizzata è stata in media di 628 Kbps. A causa della bufferizzazione del filmato si sono verificati picchi minimi e massimi di utilizzo della banda, tra i 337,9 Kbps e i 1318,9 Kbps

13 Ecco un grafico preso in contemporanea su bigticket: La banda media utilizzata si discosta poco dal valore registrato su twm. I due streaming hanno registrato prestazioni complessive simili, nonostante valori minimi e massimi differenti. Ricordando che nel frattempo su bigticket si aveva un trasferimento ftp, ecco uno screenshot catturato nei medesimi istanti: Prova 2 Dalla posizione descritta abbiamo effettuato con twm solo lo streaming. Si notano varie discontinuità nel grafico e qualche pacchetto perso anche se in percentuale bassa. La larghezza di banda media si è abbassata notevolmente, portandosi a 457,7 kbps. A livello visivo si è notato qualche rallentamento nelle immagini che restavano comunque di qualità accettabile

14 Per quanto riguarda il solo trasferimento ftp, ecco il risultato ottenuto: Il valore registrato è circa il 20% più basso rispetto a quello ottenuto in condizioni eccellenti

15 Ora si prenda in considerazione il caso seguente, in cui twm effettua lo streaming dello stesso file video e bigticket un trasferimento ftp. Figura 1: streaming di twm Figura 2: trasferimento ftp di bigticket Come si può notare, la banda media misurata per lo streaming di twm ha subito un ulteriore decremento (381,6 Kbps). Il numero di pacchetti persi è parecchio elevato, 652 (11,87%), e questo si è tramutato in un decremento prestazionale con vistosi rallentamenti del flusso video. D altro canto, anche la banda utilizzata da bigticket per il trasferimento ftp si è ridotta notevolmente, passando dai 4,99 Mbps registrati in condizioni di collegamento eccellente (vedi Prova 1) ai 2,69 Mbps attuali

16 Prova 3 Al solito, come prima prova abbiamo effettuato un unico streaming del file video. Il bit rate massimo raggiunto in fase di bufferizzazione si è abbassato, mentre il valore medio della larghezza di banda finale è rimasto in linea con i valori registrati durante la prova numero 2. La riproduzione del filmato non è stata continua, ma si sono verificati ulteriori bufferizzazioni oltre a quella iniziale. Il numero di pacchetti persi è triplicato (da 0,77% a 2,25%). Vediamo ora il risultato ottenuto per il solo trasferimento ftp: Stavolta il degrado delle prestazioni è notevole, ben l 88% circa in meno rispetto al caso di condizioni eccellenti e l 84% rispetto al caso di condizioni buone. Successivamente, si è provveduto ad effettuare un trasferimento ftp su bigticket e un file streaming su twm

17 Figura 3 - Streaming su twm Figura 4 - Trasferimento ftp su bigticket Rispetto alla prova precedente (prova 2, trasferimento ftp più streaming) si sono verificati vistosi peggioramenti. Il valore medio della larghezza finale di banda è sceso da 381 Kbps a 297 Kbps, così come i valori di picco. Il numero di pacchetti persi è notevolmente aumentato, passando dall 12% al 40% circa, causando quei fenomeni di bufferizzazione osservati. La banda del trasferimento ftp è scesa da un valore di 2,69 Mbps fino a un valore medio di 846,61 Kbps

18 Tabella riassuntiva dei risultati - Streaming di un file video * Signal Strength Signal Quality Streaming Maximum Bandwidth (Kbps) Streaming Average Bandwidth (Kbps) Streaming - Packet Loss Excellent 96 % 100 % % Good 56 % 95 % % Fair 37 % 63 % % Tabella riassuntiva dei risultati - Solo trasferimento FTP * Signal Signal FTP Average Bandwidth Strength Quality (Kbps) Excellent 96 % 100 % Good 56 % 95 % Fair 37 % 63 % Tabella riassuntiva dei risultati - Streaming di un file video in contemporanea ad un trasferimento FTP * Signal Strength Streaming Signal Maximum Quality Bandwidth (Kbps) Streaming Average Bandwidth (Kbps) Streaming - Packet Loss FTP Average Bandwidth (Kbps) Excellent 96 % 100 % 1484,1 696,5 0 % 4990 Good 56 % 95 % % 2690 Fair 37 % 63 % %

19 Test di Streaming e traffico sintetico UDP (generato con Iperf) Questa serie di test è stata effettuata utilizzando Iperf, di cui ampia documentazione si trova presso questo indirizzo. Nel dettaglio, ecco la configurazione utilizzata per questa serie di test: un notebook (bigticket) ha funzionato da server Iperf, lavorando in ambiente Windows; l'altro notebook (twm) ha effettuato, in due prove delle tre previste, uno streaming del file video War3_Gameplay_ECTS_2001.mp4 presente sul server Darwin pp4.ce.unipr.it attraverso il protocollo rtsp. l'host parma01.ce.unipr.it, collegato alla rete locale 10/100, è servito da client Iperf in grado di generare traffico udp. A margine di questo va detto che tutte e tre le prove previste sono state svolte in condizioni di segnale eccellente e dopo aver verificato l'assenza di altri host associati all'access Point utilizzato. Di seguito viene data una breve presentazione delle tre prove: 1. Generazione di traffico UDP tra client e server senza limitazioni di banda; 2. Generazione di traffico UDP tra client e server senza limitazioni di banda, e contemporaneo streaming video; 3. Generazione di traffico UDP tra client e server con limitazione di banda a 6 Mbps, e contemporaneo streaming video. 1 TEST La prima prova è servita per stabilire il throughput massimo della rete su protocollo UDP e in assenza di altro traffico. I pacchetti, tra la postazione fissa e quella mobile, transitano per il router del laboratorio Parma2 (MrsQuickly) e per quello di palazzina (Verdi), quindi per l'access Point ( ). Si considera trascurabile il decremento di prestazioni introdotto dai due router wired

20 La sintassi utilizzata per generare traffico UDP è la seguente:./iperf -s -u -i 1 per abilitare il server (bigticket) a stabilire connessioni udp con un client;./iperf -c parma01.ce.unipr.it -u -b 11M -t 160 -i 1 dal lato client (parma01). Nella tabella è riassunto brevemente il significato dei parametri utilizzati. Parametri Significato -s esegue in modalità server -c esegue in modalità cliente (specificando il server a cui connettersi) -u utilizza il protocollo udp -b ampiezza di banda da utilizzare (in bps) -t durata della trasmissione (in secondi) -i intervallo di segnalazione delle statistiche (in secondi) In questo test abbiamo imposto un'ampiezza di banda di 11 Mbps, limite teorico del protocollo b, ben sapendo che non sarebbe comunque stata raggiunta. Il risultato ottenuto è comunque notevole, come il valore medio di 6.61 Mbps registrato dimostra. Qui di seguito viene riportato un grafico riportante l'andamento completo del test

21 - 21 -

22 Come si vede dal grafico dell'ampiezza di banda, dopo un burst iniziale in cui si sono registrati valori più alti, l'andamento del traffico sinetico generato da iperf si è stabilizzato su valori piuttosto costanti, salvo tre momenti in cui si sono verificati bruschi rallentamenti dovuti alle condizioni congiunturali della rete, cui corrispondono nel grafico sottostante un'elevata percentuale di pacchetti persi. Il valore medio (in percentuale) di pacchetti persi rispecchia quanto registrato per l'andamento della banda: i pacchetti sono stati inviati dal client a 11 Mbps e, in media, ricevuti a 6,61 Mbps, ovvero circa il 40% in meno della banda effettiva a disposizione. In assenza di contese possiamo quindi stimare un'ampiezza di banda effettiva per la rete in esame attorno ai 6.5 Mbps

23 2 TEST Al fine di studiare il comportamento del traffico udp generato da iperf (sempre senza forzare limitazioni sulla banda) in presenza di altro traffico sull'access Point, si è effettuato in contemporanea uno streaming di un file video sull'host twm attraverso il player RealOne per Windows. Il file è codificato con un bitrate di 568 kbps. Come prima cosa è stato avviato il trasferimento iperf, successivamente (dopo circa 6-7 secondi) lo streaming video. Il grafico mostra la situazione dettagliata:

24 Come si può notare, l'ampiezza di banda si è mantenuta praticamente costante attorno ad un valore medio di 6.36 Mbps. A livello prestazionale si è registrato un calo rispetto al valore medio registrato nel primo test, del 3.8%, un valore comunque trascurabile. Di seguito mostriamo un paio di screenshots catturati da twm:

25 Lo streaming ha risentito di molto rispetto al caso precedente registrando una ampiezza di banda media di Kbps. Questo valore non è sufficiente a garantire la visione del filmato, a livello visivo si sono notate perdite massicce di frame che hanno comportato interruzioni della riproduzione anche prolungate. La percentuale di pacchetti persi (34.29 %) corrobora quanto appena detto

26 3 TEST Visto il risultato precedente si è quindi pensato di procedere adottando la stessa tipologia di test, ma limitando l'ampiezza di banda a 6 Mbps

27 Come prima cosa va fatto notare che la banda assegnata è stata pienamente sfruttata dal traffico udp generato da iperf: l'ampiezza di banda finale media è infatti pari a 5.98 Mbps, ovvero solamente lo 0.3% in meno rispetto a quella assegnata come dimostra anche la media dei pacchetti persi

28 Lo streaming ha evidenziato prestazioni accettabili, rientrando nella banda residua lasciata dal traffico udp di iperf. Non è un risultato ottimale in quanto la codifica del filmato si attesta a 568 Kbps e la ampiezza di banda media si è attestata a 490,8 Kbps. Il risultato visivo è risultato comunque ottimo e senza rallentamenti e non sono stati persi pacchetti

29 Test di Streaming Multiplo e traffico sintetico UDP Questa serie di test è stata effettuata utilizzando Iperf, di cui ampia documentazione si trova presso questo indirizzo. Nel dettaglio, ecco la configurazione utilizzata per questa serie di test: un notebook (bigticket) ha funzionato da server Iperf, lavorando in ambiente Windows; 3 notebook (twm, macduff, latitude) hanno effettuato uno streaming contemporaneo del file video War3_Gameplay_ECTS_2001.mp4 presente sul server Darwin pp4.ce.unipr.it attraverso il protocollo rtsp. l'host parma01.ce.unipr.it, collegato alla rete locale 10/100, è servito da client Iperf in grado di generare traffico udp. Si è cercato di effettuare le prove in assenza di altro traffico derivante da ulteriori host associati al medesimo access point ( ). Di seguito viene data una breve presentazione delle prove: 1. Determinazione dell'ampiezza di banda massima di traffico udp sintetico tale che tre client in streaming non vengano influenzati; 2. Determinazione dell'ampiezza di banda massima di traffico udp sintetico tale che due client in streaming non vengano influenzati; 3. Determinazione dell'ampiezza di banda disponibile in presenza di sei streaming video contemporanei

30 1 TEST Si è stimato un valore di banda limite reale di 7.5 Mbps tra un host e l'access point. A questo valore sono stati sottratti 1.8 Mbps, ovvero la banda teorica a regime necessaria per effettuare tre streaming del file preso in considerazione. A questo punto si è proceduto alla generazione di traffico udp con iperf limitando la banda a 5.7 Mbps ( = 5.7 Mbps) e, pochi secondi dopo l'avvio di iperf, sono stati avviati in contemporanea i tre streaming

31 Come si può osservare dai grafici, il limite di banda assegnato è stato praticamente raggiunto in termini di ampiezza di banda media (5.57 Mbps), come la bassa percentuale di pacchetti persi dimostra (2.3%). Di seguito sono visualizzate alcune capture prese su twm e macduff rispettivamente:

32 Come si può notare, gli streaming hanno ottenuto prestazioni non soddisfacenti, mettendo in evidenza anche vistosi rallentamenti; si conclude che la banda assegnata per il traffico di iperf è troppo elevata per garantire una normale visualizzazione del filmato su tutti gli host. Per trovare una valore di ampiezza di banda tale da permettere uno streaming efficiente si è quindi cercato di ridurre il valore iniziale di 5.7 Mbps; prima si è assegnata ad iperf una banda di 5 Mbps (4.56 Mbps registrati) e successivamente di 4 Mbps (3.78 Mbps registrati), ma entrambi tali valori sono risultati eccessivi per lo scopo del nostro esperimento. Un valore accettabile è risultato 3 Mbps: iperf raggiunge tranquillamente questo valore (2.99 Mbps, con una perdita di pacchetti dell'ordine di 0.26%), e tutti e tre gli streaming si sono svolti con una buona qualità. Di seguito riportiamo alcuni grafici che dimostrano i risultati ottenuti

33 - 33 -

34 Figura 1: traffico udp iperf a 4 Mbps

35 Figura 2: streaming su twm (in alto) e macduff (in basso) e iperf a 4 Mbps

36 - 36 -

37 Figura 3: traffico udp iperf a 3 Mbps.

38 Figura 4: streaming su twm (in alto) e macduff (in basso) e iperf a 3 Mbps

39 2 TEST In questa seconda prova si è cercato un valore di ampiezza di banda per il traffico udp di iperf tale da permettere il contemporaneo (ed efficiente) svolgimento di soli due streaming video. Si è partiti da una valore ipotetico, dedotto dall'esperienza precedente, di 5.5 Mbps. Tale valore è risultato comunque troppo elevato, e il test non è nemmeno stato portato a termine vista l'evidente difficoltà di riproduzione dei filmati. Si è quindi abbassata la banda assegnata a iperf, impostandola a 5.2 Mbps: il valore finale medio registrato è stato di 4.91 Mbps con una perdita di pacchetti del 5.5%. Ancora una volta la riproduzione dei filmati ha mostrato una qualità tutt'altro che soddisfacente, a conferma che il valore scelto è troppo elevato. Abbassando ancora tale soglia per il traffico udp a 4.8 Mbps si sono ottenuti risultati molto buoni: il valore finale medio dell'ampiezza di banda registrato è stato di 4.80 Mbps con una perdita di pacchetti dello 0.018%

40 - 40 -

41 I grafici sottostanti mostrano che la riproduzione del filmato su twm è stata soddisfacente, nonostante il valore medio della larghezza di banda non ha raggiunto i 568 Kbps della codifica del filmato. Tuttavia si è registrato un alto valore di picco ( Kbps) e una perdita di pacchetti nulla, e quindi una conseguente visualizzazione fluida del filmato

42 3 TEST In questo ultimo test si sono effettuati più streaming in contemporanea, per la precisione sei. Gli host sono stati associati tutti al medesimo access point ( ), ed è stato assicurato che non fossero presenti altre fonti di traffico. Tutte e sei le postazioni hanno utilizzato la stessa scheda di rete PCMCIA Cisco Aironet 350 Series e il player RealOne in ambiente Windows. Scopo dell'esperimento è stato determinare quanta banda viene messa a disposizione effettivamente nel caso di molte associazioni sullo stesso access point. Su tutti gli host si è registrato all'incirca lo stesso valore medio di larghezza di banda, ovvero 480 Kbps; questo significa che la banda effettiva di cui hanno usufruito i sei client è stata inferiore ai 3 Mbps totali. Teoricamente sei streaming con codifica a 568 Kbps dovrebbero rientrare ampiamente nei circa 6.5 Mbps stimati per il canale nei test precedenti. I filmati quindi avrebbero dovuto registrare un valore finale medio di larghezza di banda maggiormente in linea con la codifica del filmato stesso. Si può ipotizzare che questa evidente riduzione di prestazioni sia dovuta al maggior numero di contese introdotte dalla presenza di più client associati all'access point. Nella pagina seguente vengono riassunti in tabella i dati registrati durante questa serie di test riguardanti streaming multipli

43 * Iperf 5.7 Mbps Iperf 5 Mbps Iperf 4 Mbps Iperf 3 Mbps Tabella 1 - Traffico udp sintetico iperf e 3 streaming video Traffico UDP iperf Average Bandwidth (Mbps) Packet Lost Percentage (%) Average Bandwidth twm (Kbps) Streaming Video Packet Lost Percentage twm (%) Average Bandwidth macduff (Kbps) Packet Lost Percentage macduff (%) *** *** Tabella 1 - Traffico udp sintetico iperf e 2 streaming video * Iperf 5.2 Mbps Iperf 4.8 Mbps Traffico UDP iperf Average Bandwidth (Mbps) Packet Lost Percentage (%) Streaming Video twm Average Bandwidth (Kbps) Packet Lost Percentage (%) *** *** *** Non sono stati registrati dati

44 Conclusioni Il throughput massimo raggiungibile nella rete b della palazzina, utilizzando il protocollo tcp è attorno ai 7 Mbps mentre utilizzando udp si riescono a raggiungere anche 7.5 Mbps, a causa del minor overhead introdotto da questo protocollo. Si tratta comunque di valori in condizioni ottimali, in cui l'host si trovi in prossimità dell'access point e non siano presenti altre associazioni. Questi valori rappresentano delle punte massime comunque differenti dai valori medi ottenuti. Le prestazioni peggiorano aumentando i client associati all'access point e/o peggiorando la qualità del segnale, per esempio allontanadosi dall'access point o incontrando ostacoli. Nel test "Streaming e tcp" si è cercato di studiare il comportamento al variare della qualità del segnale. Passando da conzioni eccellenti a condizioni buone di link status si registra una perdita circa del 20% sul tcp e 32% per lo streaming (rispetto ai valori medi). Per condizioni buone si è inteso l'host collocato a 20 metri dall'access point e la porta in plexiglass all'ingresso della palazzina. Passando poi a condizioni sufficienti (all'esterno della palazzina) le prestazioni diminuiscono drasticamente per entrambi i protocolli. Possiamo quindi dire che le prestazioni non diminuiscono linearmente con la qualità del segnale ma, superata la distanza delle condizioni eccellenti il degrado risulta aumentare molto velocemente. I test successivi sono stati svolti in condizioni di segnale eccellenti (in lab.workstation, in prossimità dell'ap ), visto che l'utilizzo maggiore dell'802.11b risulta essere quello. Tramite il test "Streaming Multiplo" abbiamo cercato di capire come vengono influenzate le prestazioni all'aumentare degli host associati allo stesso access point. In particolare si è utilizzato

45 solamente traffico udp, generato con iperf e mandato in streaming da un server darwin su rete fissa. Con due streaming e un traffico sintetico iperf siamo riusciti a ottenere una banda complessiva di circa 5.74 Mbps nel caso ottimale (inteso come quel valore limite tale per cui le prestazioni non degradano). Con tre streaming e un traffico sintetico iperf la banda utilizzata complessivamente nel caso ottimale risulta di poco più di 4.5 Mbps. Passando al test con sei stazioni in streaming associate allo stesso access point abbiamo ottenuto una banda complessiva pari a circa 3 Mbps. Le prestazioni diminuiscono quindi drasticamente all'aumentare delle stazioni associate. Si può ipotizzare che questa evidente riduzione di prestazioni sia dovuta al maggior numero di contese introdotte