Added piattaforme lessons

Piattaforme Software per la Rete/MOD1/lesson_10.md

@@ -0,0 +1,129 @@
+# Piattaforme e Software per la rete - lezione 10
+#### Giacomo Verticale
+###### 15 April 2016
+## Scheduler Deficit Round Robin (DRR)
+Lo scheduler round robin classico risulta iniquo nel caso ho pacchetti 
+di dimensione variabile, una delle implementazioni per simulare un round 
+robin su pacchetti di dimensione variabile è il __Deficit Round Robin__
+
+Ho una serie di code su cui accumulo ad ogni turno una serie di permessi
+Se i permessi sono sufficienti a trasmettere, posso trasmettere,
+altrimenti li accumulo.
+Per ogni coda ho:
+- Qi (quanto) costante nel tempo
+- Di (deficit) variabile nel tempo
+
+Quando visito la coda i-esima calcolo il nuovo Di
+Di = Di + Qi
+Finchè Di >= Li (Li= lunghezza primo pacchetto)
+trasmetto il primo pacchetto.
+Quando la coda che sto servendo non ha più pacchetti, non accumula deficit,
+La mia idea è di trasmettere qualcosa ad ogni iterazione, per questo posso
+fare il quanto grande come il più grande pacchetto possibile.
+Faccio in modo che rimangano nella lista solo le code attive:
+- Le code che hanno trasmetto vengono messe in fondo alla coda dopo la visita
+- Le code che non hanno più pacchetti da trasmettere vengono rimosse dalla lista.
+
+### Esempio
+CODE:
+- 20,750,200
+- 500,500
+- 200,600,100
+- 50,700,180
+Qi=500 per ogni i
+Simulare DRR indicando ad ogni tempo Di quali pacchetti sono trasmessi
+
+Round | Coda | Di iniziale | Di finale | L pacchetto Tx | FineTx
+---   | ---  | --- | --- | --- | ---
+1     | 1    | 0   | 300 | 200 | 200
+1     | 2    | 0   | 0   | 500 | 700
+1     | 3    | 0   | 400 | 100 | 800
+1     | 4    | 0   | 320 | 180 | 980
+2     | 1    | 300 | 50  | 750 | 1730
+2     | 3    | 400 | 300 | 600 | 2850
+2     | 3    | 300 | 0   | 200 | 3050
+2     | 4    | 120 | 0   | 50  | 3800
+
+## Esercizi
+### Esercizio Algoritmo RED
+Assumendo lunghezza media della coda costante, calcolare
+la distribuzione di probabilità e valore atteso
+del numero di pacchetti tra due eventi di scarto successivi
+nei due casi:
+- il nodo scarta con probabilità p
+- il nodo scarta con probabilità pd = p /1-cp  con c= numero di pacchetti da ultimo scarto
+
+a: chiamo X il numero di pacchetti tra due scarti
+`Pr(X=x) = (1-p)^X*p`
+x | Prob
+--- | ---
+0 | p
+1 | (1-p)p
+2 | (1-p)^2p
+
+è una distribuzione di tipo geometrico (quanti fallimenti prima di un successo)
+
+b: Pr(X=x) = p / 1-(x-1)p
+$ p/(1-(x-1)p) /sigma^(x-2)_(c=0) (1-p/(1-cp)) =$ //p se 1<=x<= 1/p
+
+
+### Esercizio di classificazione
+_p
+- Definire il bitvector per ogni campo
+- Applicare l'algoritmo a (A,D,80,23,TCP)
+Ip Src | IP Dst | Port Src | Port Dst | Prot
+---    | ---    | ---      | ---      | ---
+A      |    *   |   53     |    80    | UDP
+B      |    C   |   123    |    80    | *
+A      |    D   |   80     |    *     | TCP
+*      |    E   |   *      |    25    | TCP
+
+Il __bitvector__ indica su quali regole matcha il pacchetto
+IP sorgente | bitvector
+--- | ---
+A | 1011
+B | 0101
+* | 0001
+
+IP destinazione | bitvector
+--- | ---
+C | 1100
+C | 1010
+E | 1001
+* | 1000
+
+Port Src | bitvector
+--- | ---
+53 | 1001
+123 | 0101
+80 | 0011
+* | 0001
+
+Resta da effettuare l'AND dei bitvector dei campi
+Campi | bitvector
+--- | ---
+A | 1011
+D | 1010
+80 | 0011
+23 | 0010
+TCP | 0111
+res | 0010
+
+### Esercizio prefissi IP
+Per codificare un prefisso di lunghezza variabile usando 33 bit
+usiamo il seguente algoritmo:
+Scriviamo i bit del prefisso seguiti da 1 e poi zeri fino a 33 bit
+- Dire quanti sono i possibili prefissi di 32bit
+- Codificare 128.0.0.0/2 128.0.0.0/3 128.0.0.0/4
+
+### Esercizio Unibit Trie
+Mostrare che il massimo numero di nodi è O(NW)
+con 
+- N = numero di prefissi e 
+- W= lunghezza massima prefisso
+Suggerimento: costruire un trie con log2N livelli e poi aggiungere
+a ogni foglia una stringa di W-log2N bit
+
+(W-log2N)N/2+N/2-1
+O(W*N)
+

Piattaforme Software per la Rete/MOD1/lesson_11.md

@@ -0,0 +1,88 @@
+# Piattaforme e Software per la rete - lezione 11
+#### Giacomo Verticale
+###### 19 April 2016
+## Misura del traffico internet
+La rete internet funziona abbastanza per quanto riguarda
+la consegna a destinazione dei pacchetti,
+per quanto riguarda le prestazioni, c'è bisogno di lavoro
+per __ingegnerizzare la rete__ 
+Fasi:
+- Misura del traffico: è necessario effettuare
+aggiornamenti della rete per tenere il passo con 
+la richiesta sempre maggiore, l'aggiornamento viene effettuato
+tenendo conto di alcune priorità
+    - input A: pianificazione della capacità
+    - accounting (billing): classificare il traffico
+    - analisi del traffico
+
+### Matrice di traffico
+Il routing di internet è *topology driven*, ed è una
+limitazione in quanto non c'è la possibilità di bilanciare
+l'utilizzo delle risorse, ad esempio sfruttando link paralleli.
+
+è una tabella che riporta per ogni coppia di nodi, quanto traffico
+entra da un nodo per andare all'altro (bit/s)
+Questa matrice viene costruita per i nodi che stanno sul confine della
+rete da considerare.
+Con N nodi sul confine abbiamo una tabella di N^2 nodi,
+con gli elementi sulla diagonale nulli, quindi N(N-1) incognite.
+Il traffico è un parametro che cambia nel tempo quindi la matrice
+sarà in funzione del tempo, anche se in questo caso consideriamo
+un tempo fissato.
+Viene sfruttato il meccanismo dell' __interface counting__ che è una
+feature presente in tutti i router e indica quanti byte o pacchetti
+sono transitati per ogni interfaccia.
+Ogni interfaccia porta a due equazioni di N incognite (una per il traffico
+in ingresso e una per quello in uscita)
+In totale ho 2N equazioni in N^2 incognite, quindi non posso risolvere le equazioni
+Dato che il numero di incognite è praticamente fisso, mi serve 
+__aumentare il numero delle equazioni__ e posso farlo
+aumentando i contatori per interfaccia (es: differenziandoli per ip o servizio)
+- Questo può portare a *milioni di contatori*.
+- Un pacchetto fa incrementare più di un contatore
+- lunghezza dei contatori
+
+Normalmente per ogni contatore si considerano 64bit, per milioni di contatori
+la memoria occupata diventa molta e non è possibile tenerli in memoria cache.
+Una strategia efficace è tenere in cache i c bit più significativi di tutti i
+contatori, suddividendoli in *verticale*
+La probabilità di andare in overflow avendo pochi bit è elevata, quindi serve
+resettare periodicamente i contatori piccoli e trasferire il conteggio sui contatori
+lunghi.
+`Ogni b accessi scelgo un contatore corto, sommo il valore al corrispondente contatore
+lungo e resetto il contatore corto`
+Quale contatore scelgo? __largest count first__
+`Copio per primo il contatore corto che ha il valore più grande, perchè è il più
+vicino all'overflow`
+
+c deve essere circa log2log2b*N (N=numero contatori*)
+Quel valore garantisce che usando l'algoritmo largest count first, non si ha mai overflow.
+Il problema dell'algoritmo lcf è che trovare il massimo impiega tempo lineare.
+Sarebbe possibile tenere memorizzato l'indice e il valore del contatore più grande,
+ma questo vale finchè non viene resettato.
+
+__Algoritmo semplificato__
+- Sia cj il contatore con il valore massimo aggiornato nel ciclo precedente di b accessi
+- Se cj >= b aggiorna e resetta cj.
+- Altrimenti aggiorna e resetta un contatore a caso perchè valga almeno b
+
+__Conteggio randomizzato__
+All'arrivo di un pacchetto aggiorna il relativo contatore con probabilità 1/c
+Mettere l'intervallo di campionamento a distanza casuale riduce il rischio di *aliasing*, 
+Cioè la sincronizzazione dell' osservazione con i fenomeni (esempio zebra nella gabbia)
+`Se un contatore vale x allora il valore atteso del numero di pacchetti è x*c`
+La *deviazione standard* è pari a qualche c
+- Se x >> c alta precisione
+- Se x ~~ c contatore inutile
+In particolare la misura degli eventi occasionali è totalmente trascurabile,
+Voglio evitare che nella misurazione si confondano eventi rilevanti ed eventi casuali.
+Un esempio di techica utilizzata è quella dell' __aggregazione a soglia__
+Esempio:
+```
+Si presenta un pacchetto con IDflusso = F
+ID flusso per connessione TCP = IPsrg||IPdst||proto||portsrg||portdst
+ID flusso per servizi destinazione = IPdst||proto||portdst
+
+Dall'ID del pacchetto calcolo tre funzioni di hash e inserisco i tre risultati in array diversi
+Se A1[h1(f)>T e così via per tutte le funzioni e array, allora salvo il flusso F
+Se il numero di pacchetti nel flusso F supera T allora Ai[hi(f)>T

Piattaforme Software per la Rete/MOD2/lesson_08.md

@@ -0,0 +1,58 @@
+# Piattaforme e Software per la rete - lezione 8
+#### William Fornaciari
+###### 14 April 2016
+## Run Time Resource Management
+Necessario per gestire come le applicazioni occupano le risorse
+di elaborazione, posso avere distinzioni tra le applicazioni,
+ad esempio alcune possono essere critiche e non interrompibili
+mentre altre possono essere ritardate se necessario.
+
+Gli obiettivi per RTRM sono:
+- __scalabilità__: il sistema deve funzionare con pochi o molti core
+- __retargetabilità__: il sistema può funzionare su architetture eterogenee.
+L'obiettivo è una __system-wide optimization__ che non si limita solo a
+ricercare delle prestazioni elevate.
+
+Un approccio per dominare e ridurre la complessità del problema 
+è agire in modo *gerarchico*, ad esempio posso avere politiche a livello
+di nodi, o di board...
+
+Quando si lavora su processori sotto i 22nm, trovo il problema della
+__process variability__ cioè un esemplare di un chip funziona
+diversamente da un altro (es: frequenza massima di funzionamento)
+o varia anche da un core all'altro.
+Per questo al momento del mapping tra cpu virtuali e cpu fisiche
+bisogna far attenzione ad alcuni dettagli (non sempre calcolabili)
+Ad esempio se il processo precedente ha scaldato la cpu, il processo
+attuale non potrà sfruttare a pieno il carico termico (problema hot-spot)
+
+Quindi serve fare __accounting__ delle risorse e __monitoring__
+
+### Working Modes
+È l'unione tra la configurazione della piattaforma di calcolo
+e la configurazione dell'applicazione, es:20fps su un quad-core a 800mHz
+Devono esserci dei punti di controllo in modo da cambiare alcuni parametri.
+E devono esserci dei punti di osservabilità per valutare i risultati.
+
+## Barbecue RTRM
+
+*Barbecue* è l'RTRM più avanzato presente sul mercato
+Barbecue effettua il mapping tra le risorse virtuali richieste dalle applicazioni
+sulle risorse fisiche attualmente disponibili.
+
+Nell'aspetto fisico della cpu, data una certa frequenza, ho una tensione minima
+per mantenerlo a quella frequenza, mentre ad una certa tensione la cpu può raggiungere
+una determinata frequenza dipendente da quest'ultima, si cerca quindi di sfruttare
+il punto più vantaggioso tra frequenza e tensione.
+
+Ho molti cicli di controllo, suddivisi su diversi livelli:
+- livello applicazione: ottimizzo utilizzo risorse
+- livello sistema: partiziono le risorse
+- livello firmware
+Quindi a grandi linee ho un sistema __gerarchico distribuito__.
+Barbecue lavora a livello __system-wide__
+
+Durante lo sviluppo di barbecue, è stato risolto il problema multiobiettivo
+del modello teorico di allocazione (simile a knapsack o tsp) ed è stata creata
+un'euristica per ottenere risultati simili al modello teorico.
+L'overhead del sistema è stato limitato al 10%