La seconda fase della tesi si `e incentrata nella valutazione delle prestazioni del throughput con il middleware ORTE. Per consentire un confronto delle misurazioni effettuate con il software RTI DDS si `e deciso di utilizzare lo stesso linguaggio di programmazione e gli stessi nodi di PlanetLab impiegati in precedenza.
Il software mette a disposizione del programmatore librerie per i linguaggi di programma-zione C++ e Java; per i motivi gi`a esposti nel capitolo precedente, si `e deciso di utilizzare il linguaggio C++. Lo strato di trasporto utilizzato `e di tipo UDP con collegamenti IPv4. `E importante ricordare che ORTE `e un software tuttora in fase di sviluppo e la versione utilizzata `e la 0.3.1. Allo stato attuale orte non `e ancora in grado di supportare tutte le QoS dello stan-dard DDS e non `e in grado di effettuare il Plugin dei messaggi inviati, quindi non `e in grado di supportare la segmentazione MTU; per tale motivo i test effettuati hanno una dimensione massima dell’evento pari ad 8 KByte.
ORTE implementa il paradigma di comunicazione RTPS nella trasmissione reliable; a dif-ferenza di RTI DDS, non sono implementate estensioni di tale paradigma che permettono di ottimizzare le prestazioni del servizio alle esigenze del caso.
6.1 Protocolli di comunicazione
Al fine di comprendere al meglio i risultati ottenuti nella fase di test, di seguito verr`a effettuata una breve descrizione dei protocolli di comunicazione implementati dal software ORTE.
ORTE permette di definire due tipi di comunicazione che sono quella best-effort e quella reliable. Con la comunicazione reliable il publisher invia messaggi dati ai subscriber; tali mes-saggi vengono momentaneamente memorizzati nella coda di mesmes-saggi in trasmissione, per la quale non `e prevista una gestione bloccante. Quando vengono generati nuovi messaggi e la coda `e piena, vengono cancellati i messaggi pi`u vecchi. Per avere conferma dell’avvenuta ricezione dei messaggi ai subscriber, il publisher invia regolarmente dei messaggi di heartbeat (HB). I subscriber verificano la ricezione dei messaggi ogni volta ogni volta che ricevono dei messaggi di HB, nel caso di mancata ricezione vengono richiesti al publisher. La comunicazione reliable contempla la possibilit`a di avere messaggi inviati e non ricevuti da tutti i subscriber interessati. ORTE consente l’invio di messaggi in modalit`a sincrona e asincrona. Nel test per la valu-tazione del throughput si utilizza la modalit`a asincrona. La modalit`a sincrona `e caratterizzata dal lato publisher dalla frequenza di invio, espressa tramite l’intervallo temporale che intercorre tra l’invio di due eventi; dal lato subscriber `e caratterizzata dall’intervallo minimo e massimo
tra l’arrivo di eventi; nel caso di una mancata ricezione nell’intervallo temporale, il middleware invoca predefinita funzione di call-back.
Con la modalit`a asincrona non `e compito del middleware invocare la funzione di call-back ogni volta che occorre inviare gli eventi, l’invio viene deciso dal programma in esecuzione, tramite l’invocazione della primitiva Send ; nel lato subscriber viene definito l’intervallo minimo tra l’arrivo di due eventi pari a zero, mentre l’intervallo massimo viene definito ad un valore illimitato per l’applicazione (nello specifico del programma throughput pari a 60 ore).
L’implementazione di un protocollo strict reliable `e possibile solo se si `e in grado di dimen-sionare la coda in trasmissione in modo che contenga tutti gli eventi generati per un periodo di tempo sufficiente ad inviare tali eventi a tutti i subscriber interessati pi´u eventuali ritrasmissio-ni. In un ambiente WAN, tale previsione non `e possibile, quindi non si `e potuta implementare una comunicazione strict reliable.
Le QoS per una comunicazione reliable sono:
tipo sottoscrizione: specifica se si vuole una sottoscrizione reliable o best-effort;
modello sottoscrizione: specifica il modo in cui il middleware avvisa dell’avvenuta ricezione di un messaggio, ovvero invocando una funzione di call-back oppure no;
repeat announce time: `e il periodo trascorso il quale il CSTWriter annuncia la sua esisitenza e la disponibilit`a di un nuovo CSChange al CSTReader; questo periodo determina quanto velocemente il protocollo recupera un dato perso;
delay response time ACK min: `e il tempo minimo che il CSTWriter attende prima di rispondere ad una richiesta di ritrasmissione;
delay response time ACK max: `e il tempo massimo che il CSTWriter attende prima di rispondere ad una richiesta di ritrasmissione;
HB max retries: indica quante volte un messaggio di HB `e ritrasmesso in assenza di risposta da parte di un subscriber prima che trascorra il timeout;
ACK max retries: indica quante volte un messaggio di ACK `e ritrasmesso in assenza di risposta prima che trascorra il timeout;
max block time: `e il timeout per la funzione di send se la coda `e piena; persistence: indica quanto a lungo un dato `e considerato valido;
send queue size: definisce la dimensione della coda di trasmissione; strength: indica la precedenza dei messaggi inviati dalla pubblicazione;
HB normal rate: indica quanto frequentemente il messaggio di HB viene inviato ai subscriber interessati;
Critical queue level: `e il valore soglia per la coda di trasmissione; indica il numero di mes-saggi che la coda pu`o contenere;
HB CQL rate: `e la frequenza di invio del messaggio di HB, quando nella coda di trasmissione si ha un numero di messaggi pari a critical queue level ;
minimum separation: indica l’intervallo temporale minimo tra due messaggi consecutivi ricevuti dal subscriber;
6.2. PROGRAMMA TEST 77
receive queue size: indica la dimensione della coda di ricezione del subscriber;
reliability requested: indica il tipo di reliability desiderato dall’applicazione subscriber; deadline: indica la durata dell’intervallo temporale all’interno del quale se non sopraggiunge
nessun messaggio viene invocato dal middleware una specifica funzione di call-back; mode: specifica il modello di sottoscrizione desiderato dal subscriber, reliable o best-effort;
6.2 Programma test
Di seguito verr`a analizzato il software prodotto per la valutazione del throughput, i valori delle QoS selezionati ed i risultati ottenuti.
Il programma assomiglia a quello realizzato con RTI DDS, si hanno due topic, identificati con il nome di Topic Data e Topic Command, sui quali transitano i dati ed i comandi di Start test ed End test. Il Topic Command `e di tipo reliable, per avere una consegna dei comandi a tutti i subscriber si sono selezionati dei valori di QoS adeguati. La selezione `e stata facilitata dalla conoscenza del numero di eventi generati e dalla frequenza di invio. Nei test in cui il Topic Command non `e riuscito ad inviare l’evento a tutti i subscriber, il test si `e scartato.
Il topic Data trasporta i messaggi contenente gli eventi generati e pu`o essere di tipo reliable o best-effort a seconda del tipo di comunicazione che si sta testando. La dimensione degli eventi inviati varia tra 16 byte ed 8192 byte, per i motivi precedentemente spiegati. Inoltre ORTE non `e in grado di autogenerare le funzioni che serializza e deserializza il dato in fase trasmissiva; `e compito del programmatore scrivere tali funzioni utilizzando le primitive messe a disposizione dal software. Per le limitazioni di tali primitive, non `e possibile inviare eventi di diverse dimensioni in una stessa esecuzione; perci`o sono state effettuate singole sessioni di test per ogni dimensione dell’evento inviato. Questa limitazione ha reso l’attivit`a di test particolarmente laboriosa, specialmente nei test su scala europea.
Ogni nodo subscriber attende un tempo indefinito il sopraggiungere sul Topic Command del camando di Start test, solo a quel punto memorizza il valore del timer locale ed inizia a contare il numero di eventi che sopraggiungono sul Topic Data. Quando sopraggiunge sul Topic Command il comando End test viene memorizzato il timer locale, e viene stimato il valore del throughput in ricezione in base ai dati raccolti in tale test.
Il publisher inizia l’attivit`a di test solo quando tutti i subscriber interessati sono registrati nel database dell’ortemanager associato all’applicazione.
I pacchetti inviati sul Topic Command e sul Topic Data hanno la stessa struttura di quelli scambiati nei test seguenti con RTI DDS. Questa scelta `e stata fatta per non falsare i risultati ottenuti.
6.3 Utilizzo del software
Per eseguire un programma di test occorre copiare le librerie di ORTE sui nodi utilizzati. In seguito occorre attivare il programma ortemanager, fornendo come parametri di input il numero di dominio interessato nell’attivit`a di test e l’elenco degli indirizzi ip dei nodi coinvoltinell’atti-vit`a di test. Se si vuole eseguire un test con tre nodi, con un dominio pari a 2, occorre utilizzare una linea di comando del tipo:
./ortemanager -d 2 -p 130.73.142.87:131.246.191.42:130.92.70.252 -D -e A questo punto `e possibile eseguire il programma.
Per l’esecuzione del publisher si ha: ./r publisher -d 2 -t 40 -R -s mentre per il subscriber best-effort ./r subscriber besteffort -d 2
I parametri utilizzabili che si possono fornire al software sono:
• Lato Publisher (r publisher)
-p {indirizzo ip}: possibile IP address di un ortemanager; -d {numero}: numero di dominio;
-R: identifica un test per la comunicazione reliable; -s {numero}: numero dei subscriber interessati;
-r {sec}: periodo di refresh dell’applicazione, cio´e ogni quanto l’applicazione si registra presso il manager locale;
-e {sec}: ipotetico tempo di vita dell’applicazione; -i {numero}: demand iniziale;
-f {numero}: demand finale;
-c {numero}: incremento del valore di demand;
-t {sec}: permette di inserire la durata del test espressa in secondi; -h: consente d’invocare l’help on-line del software;
-q: invoca l’uscita del software;
• Lato Subscriber (r subscriber reliable o r subscriber besteffort) -p {indirizzo ip}: possibile indirizzo ip di un manager; -d {numero}: numero di dominio;
-r {sec}: periodo di refresh dell’applicazione, cio´e ogni quanto un’applicazione si registra presso il proprio ortemanager;
-e {sec}: ipotetico tempo di vita di un’applicazione; -i {indirizzo ip}: indirizzo ip locale;
-q: consente l’uscita dal software; -h: help on-line del software;
6.4 Test Best-Effort
I test best-effort su scala nazionale hanno prodotto i risultati visualizzati in figura 6.1. Come si pu`o osservare, il throughput in trasmissione (Pub Best-effort) presenta un andamento crescente al crescere della dimensione degli eventi generati; il valore del throughput in ricezione registrato dai subscriber (Sub Best-effort 1, Sub Best-effort 2) presenta anche esso un andamento crescen-te. Per eventi di dimensione pari a 4096 byte e 8192 byte si ha una differenza notevole tra throughput in trasmissione e ricezione.
Per ci`o che riguarda la scala europea, si sono registrati valori del throughput raffigurati in figura 6.2; si pu`o notare un andamento crescente del throughput in trasmissione, simile ad una crescita esponenziale; mentre il throughput in ricezione si va ad assestare intorno al valore soglia
6.4. TEST BEST-EFFORT 79
Figura 6.1: Andamento del throughput in trasmissione e ricezione per le comunicazioni best-effort, su scala nazionale.
Figura 6.2: Andamento del throughput in trasmissione e media dei throughput in ricezione dei vari subscriber.
Figura 6.3: Andamento del throughput in trasmissione, su scala nazionale ed europea, con comunicazioni best-effort.
Figura 6.4: Andamento del throughput in ricezione, su scala nazionale ed europea, con comunicazione best-effort.
6.5. TEST RELIABLE 81
di 18 Mbit/sec. Si pu`o osservare come il throughput in ricezione e trasmissione presentano lo stesso andamento nella scala nazionale ed europea.
Per valutare la scalabilit`a del midleware `e stato fatto un confronto, l’andamento del throu-ghput in trasmissione e ricezione nella scala nazionale ed europea. In figura 6.3 viene raffigurato l’andamento del throughput in trasmissione su scala europea e nazionale, si pu`o notare che il middleware non presenta problemi di scalabilit`a, almeno limitatamente alle valutazioni che si sono potute effettuare con dimensioni degli eventi fino a 8 Kbyte. La scala europea ha un nume-ro di nodi dieci volte superiore rispetto alla scala eunume-ropea; a fnume-ronte di tale crescita il thnume-roughput in trasmissione presenta un andamento molto simile alla scala nazionale non risentendo della crescita dei nodi. Per ci`o che rigurda il throughput in ricezione, si pu`o osservare che la ricezione su scala europea `e circa la met`a di quella rigistrata su scala nazionale.
6.5 Test reliable
La comunicazione reliable `e influenzata dai valori associati alle QoS; per tale motivo si `e svolta un’attivit`a preliminare di ricerca dei valori pi`u appropriati. Si `e deciso dove possibile di attuare scelte simili a quelle effettuate per le QoS del software RTI DDS; in particolare la coda di messaggi in trasmissione e ricezione sono uguali.
Nella scala nazionale sono stati selezionati tre insiemi di QoS, etichettati con Ins. 1, Ins. 2, Ins. 3. Nella tabella 6.1 sono riportati i valori delle QoS associati.
QoS Ins. 1 Ins. 2 Ins. 3 HB normal rate 10 ms 40 ms 80 ms
CQL level 199 199 199
HB CQL rate 10 ms 40 ms 80 ms HB max retries 15 15 15 send queue size 200 eventi 200 eventi 200 eventi receive send queue 200 eventi 200 eventi 200 eventi
ACK Max retries 15 15 15 max block time 15 sec 15 sec 15 sec delay responce ACK Min/Max 0 0 0
repeat announce time 50 ms 50 ms 50 ms
Tabella 6.1: QoS delle comunicazioni reliable su scala nazionale, del software ORTE.
La send queue size e la recive queue size sono stati dimensionati con 200 eventi, invece di 400 come RTI, in quanto tale valore penalizzava fortemente le performance del software per eventi di dimensione maggiore; di conseguenza il valore di CQL level `e stato associato il valore di 199. I valori di ACK Max retries e max block time sono stati selezionati in base ad evidenze sperimentali. Alle QoS delay responce ACK Min/Max `e stata associato valore zero per permettere alle applicazioni di rispondere immediatamente ad un messaggio di ACK. Il valore di HB normal rate `e stato modificato in ogni insieme di QoS per consentire di valutare l’impatto di questa QoS sul throughput in trasmissione e ricezione; per avere un invio ad una frequenza costante i stesi valori spono stati associati ad HB CQL level. I risultati dei test sono riportati nelle figure 6.5, 6.6 e 6.7. Si pu`o notare che il throughput in trasmissione varia notevolmente nelle varie comunicazioni provate, ci`o mette bene in luce l’importanza e l’impatto delle QoS sul
Figura 6.5: Anadamento del throughput in trasmissione e ricezione, su scala nazionale con comunicazione reliable QoS Ins. 1.
Figura 6.6: Andamento del throughput in trasmissione e ricezione, su scala nazionale con comunicazione reliable QoS Ins. 2.
6.5. TEST RELIABLE 83
Figura 6.7: Andamento del throughput in trasmissione e ricezione, su scala nazionale con comunicazione reliable QoS Ins. 3.
throughput in trasmissione. Si pu`o notare che il throughput in ricezione presenta sempre valori molto bassi per eventi di dimensione maggiore, quasi prossimi allo zero per eventi di 8Kbyte.
Nella scala europea sono stati selezionati due insiemi di QoS, i cui valori sono riportati nella tabella 6.2. Il risultato dei test effettuati `e riportato nelle figure 6.8 e 6.9; come si pu`o osservare l’andamento del throughput `e uguale a quello rilevato su scala nazionale. Anche in questo caso `e evidente il forte impatto delle QoS sul throughput in in trasmissione per eventi di dimensione superiore ai 1024 byte. Il throughput in trasmissione, con le QoS Ins. 2, raggiunge valori di picco prossimi ai 7 Mbit/sec per eventi di dimensione 8192 byte e segue un andamento crescente al crescere della dimensione degli eventi. Tale andamento `e dovuto ad un rate di invio dei pacchetti di hearthbeat meno frequente della comunicazione con QoS Ins. 1. S pu`o osservare che l’invio pi`u o meno frequente dei pacchetti di hearthbeat non influenza molto il throughput in ricezione.
Per valutare la scalabilit`a del middleware, si `e effettuato un confronto su scala della comuni-cazione reliable, come mostrato in figura 6.10; si pu`o osservare che il middleware presenta pro-blemi di scalabilit`a , in quanto il throughput in trasmissione presenta un calo delle performance nella scala europea rispetto a quella nazionale. Il calo delle prestazioni non `e proporzionale al-l’incremento del numero dei sottoscrittori tra la scala nazionale ed europea; infatti al-l’incremento dei subscriber nella scala europea `e dieci volte superiore a quelli utilizzati nella scala nazionale; a fronte di tale aumento `e presente un decremento del throughput europeo pari ad un quarto del valore nazionale.
Un altro confronto interessante `e quello con la comunicazione best-effort, mostrato in figura 6.11 e 6.12; si pu`o osservare che la comunicazione reliable presenta dei valori del throughput in trasmissione e ricezione molto inferiori alla comunicazione best-effort, tale fenomeno in parte `e
QoS Ins. 1. Ins. 2. HB normal rate 40 ms 100 ms CQL level 199 199 HB CQL rate 40 ms 100 ms HB max retries 15 15 send queue size 200 eventi 200 eventi recive send queue 200 eventi 200 eventi ACK Max retries 15 15
max block time 15 sec 15 sec delay responce ACK Min/Max 0 0
repeat announce time 50 ms 50 ms
Tabella 6.2: QoS delle comunicazioni reliable su scala europea, del software ORTE.
Figura 6.8: Andamento del throughput in ricezione e trasmissione, su scala europea con comunicazioni reliable QoS Ins. 1.
6.5. TEST RELIABLE 85
Figura 6.9: Andamento del throughput in ricezione e trasmissione, su scala europea con comunicazioni reliable QoS Ins. 2.
Figura 6.10: Confronto su scala del throughput in trasmissione e ricezione, con comunicazione reliable.
Figura 6.11: Confronto del throughput in trasmissione tra comunicazioni best-effort e reliable, su scala europea.
Figura 6.12: Confronto del throughput in ricezione tra comunicazioni best-effort e reliable, su scala europea.
6.5. TEST RELIABLE 87