Added 3 lessons of piattaforme

Piattaforme Software per la Rete/MOD1/lesson_08.md

@@ -0,0 +1,57 @@
+# Piattaforme e Software per la rete - lezione 8
+#### Giacomo Verticale
+###### 8 April 2016
+## Switching
+
+Gli switch pososno essere realizzati con tecniche diverse:
+- Architettura a BUS
+- Matrice di crossbar:
+Una matrice con un bus per ogni coppia ingresso uscita
+L'architettura __crossbar__ ha il difetto di essere costosa
+Ci sono architetture a più stadi che permettono di ottenere lo stesso
+livello di connettività con metto punti di incrocio necessari.
+Lo __scheduling della crossbar__ consiste nel decidere in ogni istante di tempo
+quali ingressi devono parlare con quali uscite.
+
+Il nostro obiettivo è:
+##### Massimizzare il numero di connessioni ingressi/uscita contemporanei.
+
+I problemi sono:
+- In ogni istante di tempo ogni ingresso/uscita deve trasmettere un pacchetto.
+- Può esserci una contesa su una porta in usita.
+
+### Algoritmi per crossbar scheduling
+#### Take a ticket
+Lavora in modo asincrono.
+Ogni *line card* (uscita) mantiene una coda distribuita per i pacchetti destinati ad essa.
+Per gestire i ticket non è necessaria una crossbar alternativa, ma basta un bus a contesa.
+Le fasi di una ipotesi sincrona sono:
+- Gli ingressi chiedono un ticket per il pacchetto più vecchio in base alla destinazione
+- L'ordine con cui vengono servite le interfacce dipende dall'algoritmo utilizzato, es: round robin
+Questo algoritmo è affetto da __head-of-line-blocking__ in quanto i pacchetti successivi al primo
+non vengono processati prima del primo anche se le loro uscite sono disponibili.
+- In un round successivo viene servita la porta successiva, che trasmette se la porta necessaria
+non è già occupata in una trasmissione.
+
+In condizioni di traffico uniforme il rendimento di questo algoritmo è del 63%
+Dato che l'efficienza non è del 100%, se tutte le interfacce sono attive, si formerà una coda.
+
+Strategie per rimediare all'head-of-line blocking.
+- Aumentare la velocità del bus interno rispetto alla velocità degli ingressi.
+Nei sistemi reali uno speedup di 4X risolve i problemi di efficienza.
+- __Virtual Output Queues__ alternativo all'Input Queuing, in cui le code
+non sono all'uscita ma all'entrata: ogni ingresso ha una coda per ogni uscita.
+
+#### Parallel Iterative Matching
+Diverso dal take a ticket per:
+- Virtual Output Queuing invece di Input Queuing
+- Richiede pacchetti di dimensione fissa e tempo in slot.
+
+PIM è intrinsecamente randomizzato, feature che non serviva in TaT per l'asyncronicità
+Fasi dell'algoritmo:
+- Richiesta: tutte le porte di ingresso spediscono informazioni sullo stato tramite una bitmap.
+(stringa di bit lunga come #code, se è vuota bit=0 se ci sono pacchetti bit=1)
+- Grant: Ciascuna uscita sceglie una porta di ingresso da servire,
+se un uscita riceve richieste da più porte di ingresso, ne sceglie una a caso.
+- Accept: Ogni ingresso sceglie un uscita, se ce ne sono multiple viene scelta a caso.
+

Piattaforme Software per la Rete/MOD1/lesson_09.md

@@ -0,0 +1,125 @@
+# Piattaforme e Software per la rete - lezione 9
+#### Giacomo Verticale
+###### 12 April 2016
+## Router pt.2
+
+Dei pacchetti che arrivano nel router viene separata l'intestazione che viene inviata al meccanismo di lookup.
+Le code nell'algoritmo take-a-ticket sono negli ingressi, le uscite sono molto semplici.
+Negli algoritmi tipo *pim* in cui si usano meccanismi di speedup interni, alzando la velocità della
+matrice di commutazione rispetto alla velocità degli ingressi/uscite
+
+### Gestione delle code in uscita
+#### Gestione del buffer
+I buffer sono di capacità finita quindi prima o poi si riempono e serve scartare i pacchetti.
+La politica di __scheduling__ determina quale pacchetto viene spedito sull'interfaccia di uscita
+che può essere quello più vecchio ma non necessariamente.
+
+__Soluzione base__
+- Gestione buffer __tail drop__: accetto pacchetti finchè il buffer è pieno
+- Scheduling fifo
+Questa soluzione base va bene per carichi leggeri.
+Il caso di test tipico è una connessione TCP perchè sono molto diffuse in internet.
+```
+|
+|
+|       -
+|     -
+|   -   
+|  /
+| /
+|-
+|
+---------------------->
+slow
+start
+```
+La crescita è esponenziale durante slow start e lineare una volta superata SSTHRESH
+- Fase esplorativa: congestion avoidance
+La differenza fra TCP Tahoe e TCP Rhyno è che a seguito di una perdita di un pacchetto
+in Tahoe si aspetta il TimeOut e si va a velocità 1, Rhyno usa un meccanismo di __fast recovery__
+che controlla il pacchetto perso nella sequenza e dimezza la velocità e abbassando SSTHRESH
+si riparte con crescita lineare.
+
+Il meccanismo di __crescita additiva__ e __decrescita moltiplicativa__ raggiunge
+un buon compromesso tra aggressività ed efficienza.
+
+I pacchetti TCP vengono inviati a burst, e arrivati ad una cerca velocità il nodo inizia a *scartare pacchetti*
+Il buffer impiega del tempo per svuotarsi, e c'è un alta possibilità che i pacchetti persi siano della stessa
+connessione, questo crea problemi al meccanismo di fast retrasmit che riesce a recuperare solo buchi di pochi pacchetti.
+Il risultato è che avendo perdite multiple si disattiva __fast recovery__, scatta Timeout e si va a velocità 1.
+
+Quindi la gestione __taildrop__ porta a perdite multiple di una stessa connessione, inoltre una volta
+che avviene un *buffer overflow* vengono penalizzate anche le sorgenti che non hanno causato la perdita
+di pacchetti.
+Inoltre ho sincronizzato la forma del throughput delle sorgenti, quindi le sorgenti si sommano nei picchi
+e negli avvallamenti e quindi non posso raggiungere una velocità elevata.
+L'ultimo problema è che la notifica della perdita di pacchetti avviene dopo quest'ultima,
+in questo modo è impossibile evitare la perdita riducendo la velocità.
+
+__Obiettivi__ per un buffer scheduling
+- Segnalare una congestione immminente alle sorgenti tcp più attive.
+- Garantire *fairness* tra sorgenti anziane e giovani (anziane hanno priorità)
+- Fornire garanzie di banda e ritardo per flusso (QoS)
+
+ ### Random Early Detection (RED)
+è un algoritmo di gestione del buffer, decide quali pacchetti ammettere nel buffer.
+- Scarto pacchetto con probabilità p
+THR equilibrio TCP è proporzionale a MSS/(RTT* sqrt(p))*
+Se il nodo è il collo di bottiglia, il punto di lavoro rimane sulla retta lineare della threshold.
+```
+|
+|
+|
+|
+|        /
+|       /
+|      /
+|_____/
+|-----------------------
+     min   max
+    thresh thresh
+```
+
+Il problema è che tutte le connessioni piccole, ad esempio quelle per richiedere una pagina web
+non sfruttano il meccanismo di congestion window TCP
+
+#### Varianti
+- Stimatori autoreferenti
+occupazione media(t)
+(1-alpha)*occupazione media(t-1)
++ alpha*occupazione attuale
+
+- Una variante di questo modello è un meccanismo che utilizza curve diverse per ogni classe di applicazioni
+e si chiama __Weighted RED__
+- __RED for in and out__
+
+### Politiche per allocazione di banda
+__FIFO__
+- Allocazione proporzionale alla richiesta di banda
+- Nessuna protezione da sorgenti greedy
+- Semplice da implementare
+
+__Priorità semplice__
+- Richiede code multiple
+- Richiede un classificatore
+- Serve in ordine di priorità
+- Servizio può essere interrompibile o non interrompibile
+Nel caso di collegamenti lenti (~10Kbit/s) ha senso distinguere tra trasmissioni interrompibili o non.
+Nelle reti moderne non viene effettuato il blocco della trasmissione di un pacchetto per trasmetterne
+un altro perchè il tempo richiesto a trasmettere il pacchetto è poco.
+
+Funziona abbastanza male se le priorità sono tante perchè i pacchetti a priorità bassa
+soffrono di starvation.
+Per risolvere questo problema, alla alta priorità viene associato un limite sulla banda utilizzata
+
+__Round Robin__
+- Necessita di un classificatore
+- Una coda per classe
+- Servo un pacchetto per ogni coda.
+- Se i pacchetti hanno lunghezza variabile funziona molto male.
+Per rendere fair round robin con dimensioni variabili si cerca di di simulare il round robin bitwise che
+è fair per definizione, ad esempio si effettua un round robin bitwise e quando viene selezionato il bit finale
+di una coda, viene inviato il pacchetto corrispondente, in questo modo si ottiene una distribuzione uniforme.
+
+
+

Piattaforme Software per la Rete/MOD2/lesson_07.md

@@ -0,0 +1,91 @@
+# Piattaforme e Software per la rete - lezione 7
+#### William Fornaciari
+###### 13 April 2016
+## Shared Memory
+Possibilità di creare un segmento di memoria condiviso per far scambiare
+i dati tra diversi processi.
+È uno dei modi più veloci per comunicare, ma è pericoloso:
+può essere necessario controllare i permessi di scrittura.
+Un alternativa sono i __memory mapped files__:
+- primitive semplici (stesse dei file)
+- prestazioni leggermente peggiori
+
+Conviene utilizzare i memory mapped files quando una normale scrittura su filesystem 
+non sarebbe abbastanza veloce.
+
+L'utilizzo della shared memory consiste in:
+- il primo processo crea un segmento di memoria e lo inizializza
+- Altri processi possono accedere al segmento condiviso
+
+La primitiva usata per la creazione è `shmget()` e necessita delle librerie 'ipc.h' e 'shm.h'
+Per poter accedere allo stesso segmento condiviso, i vari processi possono usare la
+chiave che viene restituita al momento della creazione.
+Il segmento più piccolo che può essere allocato è 1 pagina, che può valere 1K,4K,...
+a seconda del sistema.
+Il terzo parametro è un valore bitwise o flag che serve a dare opzioni o 
+impostazioni di sicurezza, le flag vanno usate in OR per ottenere la sequenza i 
+bit di opzioni finali.
+La sincronizzazione migliore viene effettuata con i semafori piuttosto che con 
+i permessi, i permessi servono per questioni di sicurezza.
+
+Con la primitiva `shmat()` che sta per shared memory attach posso collegare il segmento condiviso
+ad altri processi.
+`smhdt()` è un modo per staccare il segmento dal processo chiamante.
+
+### Ciclo di utilizzo di una shared memory
+Operazioni necessarie:
+- Creazione del segmento condiviso
+- Attaccare il segmento a tutti i processi che lo devono usare
+- Staccare il segmento dai processi che hanno finito di usarlo
+- Deallorare il segmento una volta che non serve più
+
+## Memory mapped files
+Diversi processi sono in grado di comunicare con un file condiviso
+In linux a basso livelli il file viene diviso in pezzi della dimensione delle pagine
+per avere un acesso ottimizzato.
+La primitiva usata per questo meccanismo è `mmap()` e dopo la chiamata
+posso accedere all'oggetto con le primitive dei file
+Il file dovrebbe sopravvivere al riavvio del computer.
+La chiamata ad `mmap()` è più flessibile rispetto alle shm ma ha più overhead
+è possibile caricare in memoria con `mmap()` anche file letti dal filesystem (con le primitive dei file)
+
+## Condivisione di dati attraverso una rete IP
+__Remote Procedure Call__ è una procedura remota bloccante eseguita nello spazio 
+di memoria della propria macchina
+Ci sono dei problemi nello scambio di dati, ad esempio può cambiare la endianness tra le due macchine
+e quindi risulterebbe complicato passare dei puntatori.
+RPC è stata la soluzione storica (vecchia di 30anni) per le architetture client server
+rpc si basa su UDP e quindi non garantisce la consegna, in base al valore di ritorno possiamo
+solo dire che la procedura è stata eseguita almeno una volta,
+risulta quindi una buona idea fare funzioni *idempotenti*, cioè che produce lo stesso
+risultato se eseguita più volte.
+__Remote Procedure Call Messages__ di solito usando __External Data Representation__ che è una
+codifica indipendente rispetto alle due macchine e che permette di trasferire i dati
+usando una codifica universale.
+
+### Meccanismo dell' RPC
+- Programma remoto si registra
+- Chiamante ottiene il numero di porta
+- Chiamante codifica i parametri e li invia al remoto
+- Remoto effettua i calcoli, codifica il risultato e lo invia al chiamante.
+
+rpcgen è il compilatore che genera gli stub per server e client.
+
+## Architetture parallele
+- __Shared memory__ in cui più processori usano una memoria condivisa
+Caratterizzati da UniformMemoryAccess (UMA), è l'architettura più semplice
+- __Message passing__ in cui ogni cpu ha una memoria privata consistente
+rispetto alla memoria condivisa, architettura NotUniformMemoryAccess (NUMA)
+- __Distributed systems__ in cui i processori comunicano attraverso internet.
+
+### Aspetti HW dei sistemi multiprocessore
+- Sistemi __UMA__
+Possono usare una matrice crossbar oppure una gerarchia di memorie (come le cache)
+Le architetture UMA funzionano bene per un basso numero di core (<16)
+La memoria condivisa può essere acceduta tramite un bus, con eventuali cache,
+i processori posso utilizzare anche una memoria privata per i conti e scrivere
+il risultato su una memoria condivisa.
+
+Le __matrici crossbar__ hanno il problema che il numero di punti cresce esponenzialmente
+quindi spesso vengono sostituite da switch a strati.
+