Relazione d`Internato di Laboratorio di Ingegneria Informatica

Dipartimento di Ingegneria dell'Informazione
Relazione d’Internato di
Laboratorio di Ingegneria
Informatica
“Prestazioni di una rete WiFi
802.11b”
Bergamini Rinaldo, Bompani Stefano
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……………………………………………………………44
-2-
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:
http://www.ixiacom.com/enterprise/Qcheck.php
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.
-3-
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 = (m1 + ... + 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:
1° Run
2° Run
3° Run
RT minimo
5 ms
5 ms
5 ms
RT massimo
14 ms
5 ms
5 ms
RT medio
8 ms
5 ms
5 ms
-4-
1.a UDP
Parametri scelti:
Protocollo: UDP
Iterazioni: 5
Data Size: 1000 bytes
Risultati:
1° Run
2° Run
3° Run
RT minimo
6 ms
6 ms
5 ms
RT massimo
6 ms
7 ms
5 ms
RT medio
6 ms
6 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-
Risultati:
1° Run
2° Run
3° Run
THROUGHPUT
4,188 Mbps
4,103 Mbps
4,014 Mbps
2 .a UDP
Parametri scelti:
Protocollo: UDP
Data Size: 1 Mb
Risultati:
1° Run
2° Run
3° Run
THROUGHPUT
3,599 Mbps
3,587 Mbps
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.
-6-
Risultati:
1° Run
2° Run
3° Run
% DATA LOST
0,00%
0,00%
0,00%
TROUGHPUT
958,068 kbps
794,941 kbps
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.
-7-
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).
-8-
2.
-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.
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.
- 10 -
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:
- 11 -
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.
- 12 -
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.
- 13 -
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.
- 14 -
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.
- 15 -
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.
- 16 -
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.
- 17 -
Tabella riassuntiva dei risultati - Streaming di un file video
Streaming
Signal Signal Maximum
*
Strength Quality Bandwidth
(Kbps)
Excellent 96 % 100 %
1658.0
Good
56 %
95 %
1469.2
Fair
37 %
63 %
1113.3
Streaming
Streaming
Average
- Packet
Bandwidth
Loss
(Kbps)
675.1
0%
457.7
0.77 %
465.3
2.25 %
Tabella riassuntiva dei risultati - Solo trasferimento FTP
*
Excellent
Good
Fair
Signal
Strength
96 %
56 %
37 %
Signal
Quality
100 %
95 %
63 %
FTP Average Bandwidth
(Kbps)
7120.0
5720.0
899.71
Tabella riassuntiva dei risultati - Streaming di un file video in contemporanea ad un
trasferimento FTP
Streaming Streaming
FTP
Streaming
Signal Signal Maximum Average
Average
*
- Packet
Strength Quality Bandwidth Bandwidth
Bandwidth
Loss
(Kbps)
(Kbps)
(Kbps)
Excellent 96 % 100 % 1484,1
696,5
0%
4990
Good
56 % 95 % 1419.0
381.6
11.87 %
2690
Fair
37 % 63 % 1257.1
296.7
39.94 % 846.61
- 18 -
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 (160.78.28.241). Si considera trascurabile
il decremento di prestazioni introdotto dai due router wired.
- 19 -
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 802.11b, 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.
- 20 -
- 21 -
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.
- 22 -
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:
- 23 -
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:
- 24 -
Lo streaming ha risentito di molto rispetto al caso precedente
registrando una ampiezza di banda media di 271.6 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.
- 25 -
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.
- 26 -
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.
- 27 -
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.
- 28 -
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
(160.78.28.241). 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.
- 29 -
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 (7.5 - 1.8 = 5.7 Mbps) e, pochi secondi dopo
l'avvio di iperf, sono stati avviati in contemporanea i tre streaming.
- 30 -
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:
- 31 -
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.
- 32 -
- 33 -
Figura 1: traffico udp iperf a 4 Mbps.
- 34 -
Figura 2: streaming su twm (in alto) e macduff (in basso) e
iperf a 4 Mbps.
- 35 -
- 36 -
Figura 3: traffico udp iperf a 3 Mbps.
- 37 -
Figura 4: streaming su twm (in alto) e macduff (in basso) e
iperf a 3 Mbps.
- 38 -
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%.
- 39 -
- 40 -
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 (1923.8 Kbps) e una
perdita di pacchetti nulla, e quindi una conseguente visualizzazione
fluida del filmato.
- 41 -
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 (160.78.28.241), 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.
- 42 -
Tabella 1 - Traffico udp sintetico iperf e 3 streaming video
Traffico UDP iperf
Streaming Video
Packet
Packet
Average
Packet
Average
Average
Lost
Lost
Bandwidth
Lost
Bandwidth
Bandwidth
Percentage
Percentage twm Percentage macduff
(Mbps)
macduff
(%)
(Kbps)
twm (%)
(Kbps)
(%)
*
Iperf
5.7
Mbps
Iperf
5
Mbps
Iperf
4
Mbps
Iperf
3
Mbps
5.57
2.3
451.9
5.95
278.2
***
4.56
8.7
422.6
***
424.8
6.74
3.78
5.5
569.1
0.0
339.0
15.44
2.99
0.26
577.2
2.68
456.5
0.28
Tabella 1 - Traffico udp sintetico iperf e 2 streaming video
*
Iperf
5.2
Mbps
Iperf
4.8
Mbps
Traffico UDP iperf
Average
Packet Lost
Bandwidth
Percentage (%)
(Mbps)
4.91
5.5
***
***
4.80
0.018
464.3
0.0
*** Non sono stati registrati dati
- 43 -
Streaming Video twm
Average
Packet Lost
Bandwidth
Percentage (%)
(Kbps)
Conclusioni
Il throughput massimo raggiungibile nella rete 802.11b 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 160.78.28.241), 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
- 44 -
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.
- 45 -