# Piattaforme e Software per la rete - lezione 4
#### William Fornaciari
###### 30 March 2016
## Modulo 2
Algoritmi di scheduling divisi in:
- Preemptive
- Non preemptive

è possibile adottare delle politiche per ottimizzare dei parametri a discapito
della fairness dello scheduling, ad esempio posso far terminare prima processi brevi
Ottenendo una risposta mediamente più rapida ma con un rischio di *starvation*.
Spesso serve integrare queste politiche con altre soluzioni per ridurre questo rischio.
Politiche:
- Shortest Remaining Time
Per processi periodici è di solito possibile stimare i tempi di esecuzione.
Processi di interazione con l'utente possono avere un utilizzo di CPU variabile,
es: algoritmi adattativi. 

- Highest Response Ratio Next
Si calcola per ogni processo 
(Tempo di servizio stimato + tempo speso ad aspettare)/Tempo di servizio stimato
E si sceglie il processo con il rapporto più alto, ovvero si mette in relazione 
il tempo di attesa con la durata del processo, es: un attesa di 1 sec pesa più su un processo
di un paio di secondi rispetto ad un processo di 5 minuti.

- Feedback Scheduling
Ho diverse code, modello ricondotto a priority queue.

- Fair-Share Scheduling
Posso raggruppare i processi e dividere il tempo della cpu tra i diversi gruppi,
quando un certo gruppo riceve la priorità, viene divisa equamente tra i processi 
che vi fanno parte in modo da garantire che determinate applicazioni abbiano 
un tempo di servizio garantito.

#### Prevedere la lunghezza del prossimo CPU burst
__Media esponenziale__
tau(n+1)=alpha t(n)+(1-alpha)tau(n)
alpha è il peso da dare all'ultima misurazione piuttosto che alle stime precedenti.
In particolare determina l'ampiezza della storia da prendere in considerazione.

- Priority Scheduling
Viene eseguito il processo con la priorità più alta, se la coda è vuota si passa a quelle successive.

- Round Robin
Si può dimostrare che non soffre di problemi di starvation, se do un tempo di slot molto
grande, degenera in una FIFO in cui il processo tiene il tempo CPU finchè non termina.
Se scelgo un tempo più piccolo il sistema sembrerà più reattivo ma aumenta l'overhead.
Il Round Robin ha un tempo medio di turnaround > di SRT ma risulta più reattivo
Una regola a spanne è che l'80% dei processi deve completare entro il quanto di tempo.

- Multilevel Queue
Posso dividere la coda di processi in ForeGround e BackGround e usare politiche diverse.

- Multilevel Feedback Queue
Ho code multiple di priorità, gestite all'interno in Round Robin
La priorità dei processi viene ricalcolata periodicamente in base a Nice e una funzione dell'uso della CPU
Così i processi che hanno usato la CPU diventa meno probabile che abbiano accesso nuovamente alla CPU.
La __Niceness__ determina la priorità iniziale, 0 è neutra, NICE>0 diminuisce la priorità, NICE<0 l'aumenta.
Questa politica è stata implementata per prima da BSD Unix ed è efficace.
Scheduler a complessità costante utilizzano un meccanismo hardware che dato un elenco di bit
uno per ogni coda, un istruzione assembler restituisce in tempo costante la posizione del primo 0.

Nei sistemi embedded un modo sicuro per eseguire task mission critical/real time è allocarci uno dei vari processori
In modo che nel caso pessimo diventa predicibile, altrimenti ci sono gli altri core per allocazione best effort.

### Multi-processor Scheduling
Nel caso di Symmetric Multiprocessing (SMP) i vari processori accedono ad una struttura dati comune
da cui prendono i processi da eseguire.

### Real-Time Scheduling
- Real Time Hardware
- Soft Real Time
Il kernel preemptable è un buon contributo al Real Time computing.

### Deterministic modeling
Può essere importante fare scheduling in funzione della temperatura target della cpu o delle varie cpu
L'analisi non sfrutta il workload reale ma contronta i vari algoritmi di scheduling verso un caso di test (benchmark)

## Applicazioni distribuite
Un applicazione distribuita può usare uno stesso cpu o più core di una sola cpu o cpu collegate via rete
ovviamente in questo ultimo caso aumenta il ritardo per la comunicazione e i consumi.
Di solito la comunicazione avviene tramite le API TCP/IP del sistema operativo.
La API standard per TCP/IP si chiama "interfaccia __socket__", presentato nel 1985 al Politecnico
da studenti di Berkley
La API permette anche l'interoperabilità tra sistemi operativi diversi.

Il protocollo più comune è quello *client/server*