Come già accennato nell’introduzione, dopo esserci dedicati al confronto tra UDP e TCP tenendo fissato il numero di keypoint per pacchetto a 50 i e variando
la qualità del canale e il valore di threshold (ovvero il numero totale di keypoint estratto da BRISK), ora affronteremo il problema di definire un ”modus operandi” ottimo per decidere il numero di keypoint da porre in ciascun pacchetto UDP. Dall’analisi delay-accuracy ci appare evidente come esista un valore di threshold in cui l’accuratezza inizi a saturare, valore oltre il quale non ha quindi senso procedere, perché crescendo il numero di byte trasmessi, e quindi il ritardo, non abbiamo un corrispondente aumento dell’accuratezza. Questa soglia è attorno al valore di threshold di 60. Nel nostro test quindi porremo come valori di threshold uno in saturazione 60 e gli altri due sul fronte ascendente, 90 e 120. Quindi, invieremo la query di ZuBuD di 115 immagini, costruendo pacchetti di dimensione variabile: prima 1000 keypoint per pacchetto (pacchetto singolo), poi 500, 250, 100, 50 e 25. Sempre variando la perdita di pacchetti dallo 0% al 10%.
iNel capitoletto per semplicità parleremo di ”keypoint per pacchetto” intendendo il numero
0 100 200 300 400 500 600 700 800 900 1000 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
Number of Keypoints per packet
MAP
Threshold 60 Threshold 90 Threshold 120
Figura 4.24: Accuratezza con perdita di pacchetti nulla al variare del threshold (60, 90 e 120)
Nella figura 4.24 vengono rappresentati i diversi livelli di accuratezza raggiunti dalle tre configurazioni di ”threshold” con perdita di pacchetti nulla. Soglia che rimane fissa anche al variare del numero di keypoint per pacchetto, quindi, com’era prevedibile, aumentando o diminuendo il numero di keypoint per pacchetto non c’è variazione di accuratezza nel caso in cui il canale sia senza interferenze.
0 100 200 300 400 500 600 700 800 900 1000 1.4 1.5 1.6 1.7 1.8 1.9 2 2.1 2.2 2.3x 10 −3
Number of Keypoints per packet
Query Delay [s]
UDP 0% UDP 2% UDP 5% UDP 10%
Figura 4.25: Ritardo con 60 di threshold al variare del numero massimo di keypoint per pacchetto 0 100 200 300 400 500 600 700 800 900 1000 6.5 7 7.5 8 8.5 9 9.5 10 10.5 11x 10 −4
Number of Keypoints per packet
Query Delay [s]
UDP 0% UDP 2% UDP 5% UDP 10%
Figura 4.26: Ritardo con 90 di threshold al variare del numero massimo di keypoint per pacchetto
Ora osservando le figure 4.25 e 4.26 che rappresentano l’andamento tra ritardo e numero di keypoint per pacchetto (rispettivamente nel caso con 60 e con 90 di threshold) possiamo osservare come ci sia un aumento del ritardo quanto più piccoli sono i pacchetti inviati. Questo fenomeno è dovuto all’aumento del peso del header nei datagrammi. Il protocollo ATC risulta più sensibile all’aumento del header rispetto a CTA in quanto trasmette una minore quantità di byte. Come ci si aspettava la differenza tra i grafici con varie qualità del canale è invece prati- camente impercettibile. Possiamo osservare come ci sia un leggero peggioramento (più percepibile nel caso con threshold di 90, dove i ritardi sono minori) dovuto al possibile ritardo introdotto dalla perdita e successivo rinvio dell’ack di ”fine invio dei dati”. In conclusione più i pacchetti sono piccoli, più subiscono il peso dei 12 byte di header sul tempo totale di invio.
0 100 200 300 400 500 600 700 800 900 1000 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
Number of Keypoints per packet
MAP
UDP 0% UDP 2% UDP 5% UDP 10%
Figura 4.27: Accuratezza con 60 di threshold al variare del numero massimo di keypoint per pacchetto
0 100 200 300 400 500 600 700 800 900 1000 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8
Number of Keypoints per packet
MAP
UDP 0% UDP 2% UDP 5% UDP 10%
Figura 4.28: Accuratezza con 90 di threshold al variare del numero massimo di keypoint per pacchetto
Nelle figure 4.27 e 4.28 vediamo il grafico accuratezza e numero di keypoint per pacchetto con 60 e 90 di threshold. In questo caso vediamo come in entrambe le situazioni ci sia una diminuzione della qualità del riconoscimento aumentando la dimensione dei datagrammi. Questa diminuzione di accuratezza è tanto più accentuata quanto più è bassa la qualità del canale. Con pacchetti piccoli infatti io ho la certezza di ricevere almeno parte dell’informazione, con pacchetti grandi invece aumenta la probabilità di perdere l’intero contenuto.
1.4 1.45 1.5 1.55 1.6 1.65 1.7 1.75 1.8 1.85 x 10−3 0.25 0.3 0.35 0.4 0.45 0.5 0.55 0.6 0.65 0.7 Query Delay [s] MAP UDP 0% UDP 2% UDP 5% UDP 10%
Figura 4.29: Grafico che raffigura il rapporto tra ritardo e accuratezza al variare del numero di keypoint e della qualità del canale
Unendo i due grafici, otteniamo la figura 4.29 in cui possiamo osservare l’an- damento dei dati in funzione del ritardo e dell’accuratezza. In questo caso non ci appare un comportamento ottimo in assoluto. Se vogliamo sfruttare al massimo l’accuratezza in qualsiasi condizione di disturbo del canale ci porremo nella parte destra del grafico, dove c’è un ritardo più alto, ma accuratezza massima grazie alla robustezza di ATC e alla frammentazione in pacchetti (pochi keypoint per pacchetto). Se invece vogliamo avere un ritardo più basso ci sposteremo sempre
più verso sinistra nel grafico e, in base al livello di accuratezza che consideriamo accettabile e alla qualità del canale stimata, sceglieremo pacchetti con sempre meno keypoint a seconda delle esigenze richieste.
4.4
Confronto CTA e ATC
Possiamo quindi procedere al confronto finale con le prestazioni nelle quattro configurazioni:
1. ATC con UDP (4.2.1); 2. ATC con TCP (4.2.2); 3. CTA con UDP (4.1.3); 4. CTA con TCP (4.1.5);
nelle varie condizioni di qualità del canale su cui avviene la trasmissione. I grafici da cui trarre il comportamento ottimo sono quelli più significativi. ovvero quelli che confrontano il ritardo della trasmissione e l’accuratezza con cui viene effettuato il riconoscimento.
4.4.1
Condizione 0% perdita di pacchetti
0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 query Delay [s] MAP UDP CTA 0% TCP CTA 0% UDP CTA 0% 1 block UDP ATC 0% TCP ATC 0%Figura 4.30: Confronto tra CTA e ATC con UDP e TCP, senza perdita di pacchetti
Nel grafico 4.30 sono rappresentate le curve nel caso in cui il canale sia in con- dizione ottima, ovvero senza perdita di pacchetti sulla rete. In questa situazione possiamo vedere come i risultati migliori siano ottenuti dalla curva celeste, ovvero da CTA usando il protocollo UDP senza frammentazione, ha le performance di velocità di trasmissione di UDP e l’accuratezza massima, grazie all’uso di SIFT nel modello CTA. La condizione senza perdita di pacchetti è altresì una condizio- ne ideale irrealizzabile se non in situazioni controllate senza nessun disturbo sulla rete. Come abbiamo visto precedentemente, UDP senza frammentazione è molto sensibile anche ad una piccola variazione della qualità del canale di conseguenza è sconsigliabile l’uso in un ambiente al di fuori di quello ideale.
4.4.2
Condizione 2% perdita di pacchetti
0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Query Delay [s] MAP UDP CTA 2% TCP CTA 2% UDP ATC 2% TCP ATC 2%Figura 4.31: Confronto tra CTA e ATC con UDP e TCP, con perdita di pacchetti del 2%
Con bassa percentuale di perdita di pacchetti (figura 4.31) possiamo osservare come le curve di ATC usando UDP e CTA usando TCP, abbiano prestazioni molti simili. La differenza fondamentale è data dal differente livello di saturazione raggiunto dalle due configurazioni, che deriva dal uso di BRISK nel caso CTA e di SIFT nel caso ATC. L’accuratezza di BRISK è circa del 10% inferiore a quella di SIFT. Quindi possiamo decidere di utilizzare ATC con TCP se non abbiamo vincoli molto stringenti di velocità di ricezione(oltre i 2ms), se invece l’obiettivo è quello di sfruttare al meglio i tempi di ricezione senza curarci della perdita di accuratezza possiamo utilizzare CTA con UDP, con la possibilità di rafforzarne le prestazioni usando pacchetti con molti keypoint (sezione 4.3).
4.4.3
Condizione 5% perdita di pacchetti
0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Query Delay [s] MAP UDP CTA 5% TCP CTA 5% UDP ATC 5% TCP ATC 5%Figura 4.32: Confronto tra CTA e ATC con UDP e TCP, con perdita di pacchetti del 5%
Aumentando la percentuale di pacchetti persi, la curva di CTA con TCP trasla verso destra, mentre la curva di ATC con UDP abbassa leggermente la soglia di saturazione. Avendo dimostrato ATC di essere un protocollo robusto alla perdita di pacchetti, il calo di accuratezza è molto limitato. Osservando la velocità di trasmissione appare quindi con maggiore evidenza la differenza nelle prestazioni. Nella parte sinistra dei grafici a parità di ritardo c’è un maggior divario tra l’accu- ratezza ottenuta da CTA con TCP e ATC con UDP. Nel caso si abbia la necessità di livelli di accuratezza attorno al 80% si ha la necessità di utilizzare CTA-TCP, altrimenti si possono sfruttare le prestazioni di ATC-UDP.
4.4.4
Condizione 10% perdita di pacchetti
0 0.002 0.004 0.006 0.008 0.01 0.012 0.014 0.016 0.018 0.02 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Query Delay [s] MAP UDP CTA 10% TCP CTA 10% UDP ATC 10% TCP ATC 10%Figura 4.33: Confronto tra CTA e ATC con UDP e TCP, con perdita di pacchetti del 10%
Peggiorando ulteriormente la qualità del canale aumenta il divario nelle pre- stazioni tra ATC-UDP e CTA-TCP. Ora la curva di ATC raggiunge la soglia di saturazione prima di intersecare la curva di CTA che è traslata ulteriormente verso la destra del grafico, ovvero è aumentato il tempo necessario per avere alti valori di accuratezza. Conseguentemente possiamo affermare che nel caso il canale sia molto disturbato, se non ho necessità di valori molto alti di accuratezza per cui devo usare CTA con TCP, è preferibile utilizzare CTA con UDP.