Test RealOne 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).
2. 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. 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:
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. 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. 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.
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.
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. 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.