2.6 Ottimizzazione delle prestazioni
3.1.1 Accuratezza dell’emulatore
L’accuratezza di un emulatore `e influenzata principalmente da due fattori: dal grado di dettaglio del modello del sistema e quanto l’hardware e il software riescono a riprodurre i tempi richiesti dal modello.
Per quanto riguarda il primo aspetto, il modello di link implementato da dummynet si basa sulle pipe (cos´ı come altri emulatori quali Nistnet e Netpath) ed `e limitato ad un canale con rate fisso. Nessuno di questi sistemi emula tutti i dettagli del MAC layer, come framing, slotting, gestione delle collisioni e ritrasmissioni a livello di link. La ragione per non modellare in modo dettagliato tutte le caratteristiche del link level `e quello di evitare l’eccessivo costo computazionale che questo comporta. Questo `e il principale motivo per cui nell’estensione wireless di dummynet si `e preferito approssimare gli effetti del layer MAC 1.2.7.
Per quanto riguarda invece il secondo aspetto – la riproduzione dei tempi calcolati dal modello – occorre considerare tre fattori: il traffico in competizione sul mezzo fisico, l’interferenza delle attivit `a del sistema operativo e la risoluzione del timer di sistema. Questi fattori saranno discussi in dettaglio nel resto di questo Paragrafo, insieme agli effetti che essi hanno sui sistemi di emulazione, non solo su dummynet. Nell’affrontare questa analisi risulta utile schematizzare il loro impatto nella seguente tabella:
Causa Errore introdotto
Traffico in competizione 120..1200 µs per link di emulazione Interferenza del Sistema Operativo 30 µs o pi `u, dipende dal SO
Il traffico in competizione sul mezzo introduce un grande, e spesso trascurato, componente di errore, che riguarda tutti gli emulatori che supportano link emulati. L’effetto del degli altri due componenti pu `o essere ridotto controllando il sistema operativo, il carico a cui esso `e sottoposto o con un’adeguata risoluzione del timer.
Traffico in competizione sull’interfaccia di uscita
In generale il funzionamento degli emulatori prevede, per ogni pacchetto che passa dall’emulatore, il calcolo di un tempo in cui il pacchetto deve essere reimmesso in rete. Alla fine di questo tempo, il pacchetto viene rilasciato al sistema operativo, che si occuper `a poi di inviarlo sul link fisico di uscita. Nel caso di un emulatore che supporta pi `u link di emulazione, i pacchetti su diversi link emulati risultano avere lo stesso tempo di uscita (o un tempo molto simile); `e inevitabile andare incontro ad una serializzazione della trasmissione sull’interfaccia fisica, il che introduce un errore inevitabile che nel caso peggiore ammonta aT = (N − 1)L/B secondi. Il valore N `e il numero di link emulati che vanno in conflitto, L `e la dimensione massima del pacchetto, eB `e la larghezza di banda dell’interfaccia di uscita. Il valore diL/Braggiunge i 1.2 ms con pacchetti di 1500 bytes su un link Ethernet a 100 Mbit/s, e 120µs su un’interfaccia al Gigabit. Questo errore pu `o essere ridotto o rimosso intervenendo sui fattori che fanno parte della formula precedente.
Interferenze dovute al sistema operativo
I sistemi operativi non real time non danno alcuna garanzia sul tempo di esecuzione dei task del kernel, (come i task legati all’emulazione) in quanto altre attivit `a del kernel a pi `u alta priorit `a possono fare preemption e interrompere il processo in esecuzione. Per determinare almeno un tempo massimo per il ritardo che possono verificarsi nello stack di rete, a causa di interferenze dovute al sistema operativo, negli esperimenti
`e stata misurata la variazione nei tempi di risposta al ping in diverse configurazioni di carico del sistema: • IDLE. Sistema completamente idle, non ci sono processi extra in esecuzione, eccetto che per i servizi
di base del sistema;
• USER. Diversi processi in esecuzione sul seguente loop extern volatile a; for(;;) a++;
in modo da consumare tutto il tempo CPU disponibile, e accedendo alla memoria del bus in user space; • KERNEL. Un certo numero di processi che accede ai dispositivi fisici ed al filesystem residente in
memoria, effettuando continue chiamate di sistema che causano un alto carico per il kernel; ed in tre differenti configurazioni dello stack di rete:
• nessun firewall; • 1 regola ipfw; • 100 regole ipfw.
Questo test riesce a riprodurre in modo simile il comportamento del kernel nelle varie configurazioni dell’em- ulatore. I risultati, sia la deviazione media che quella standard, sono rappresentate nella tabella seguente (tutti i tempi sono espressi inµs):
IDLE USER KERNEL
avg sd avg sd avg sd
no ipfw 27.2 1.94 27.6 1.72 49.7 2.50 IPFW-1 28.1 2.82 28.2 1.36 55.1 2.62 IPFW-100 36.2 1.82 36.3 1.78 71.0 2.60
0
0.2
0.4
0.6
0.8
1
9
9.2
9.4
9.6
9.8
10
CDF
Delay (ms)
Variable HZ, async sender
1K
2K
4K 10K
40K
0
0.2
0.4
0.6
0.8
1
9
9.2
9.4
9.6
9.8
10
CDF
Delay (ms)
HZ=1000
Interval=10.2ms
test #1test #2
Interval=10.5ms
ping -f
Figura 3.1: Distribuzione dei ritardi per una pipe con un delay di 10 ms. In alto: HZ variabile, sender asincroni; in basso: HZ=1000, sender sincroni.
L’analisi dei tempi assoluti dei risultati non ha particolare interesse, invece la differenza tra il caso base (IDLE) e le corrispondenti colonne degli altri casi, a parit `a di condizioni di carico, risulta pi `u interessante. I risultati fanno emergere che per un carico di tipo USER, non importa quando elevato sia, si ha un impatto trascurabile sul sistema, mentre un carico di tipo KERNEL introduce un ritardo addizionale: negli esperimenti condotti i pacchetti subiscono un ritardo di 20-35µsecondi.
Questo tipo di errore pu `o essere ridotto controllando accuratamente le condizioni in cui opera il sistema operativo, o addirittura escludendo del tutto il suo intervento. Questo tuttavia non `e sempre possibile, in particolare quando l’emulatore `e in esecuzione sulla stessa macchina utilizzata per condurre gli esperimenti.
Risoluzione del timer
dummynet (e molti altri emulatori), internamente arrotondano i tempi in base al quanto definito dal timer di sistema, HZ volte per secondo, (nel nostro caso HZ=1000). Questo introduce un errore relativo al timer di 1/HZ = 1 ms, che pu `o essere ancora ridotto impostando il timer di sistema ad un rate pi `u elevato (ad esempio diversi test sono stati effettuati configurando HZ=10000 o 40000 corrispondenti ad errori dell’ordine di25..100 µs) o affidandosi a timer ad alta risoluzione che diversi sistemi operativi rendono disponibili.
In Figura 3.1, in alto, `e visualizzata la distribuzione dei ritardi per una pipe con un ritardo nominale di 10 ms delay, utilizzando diversi valori per il tick del timer. Come ci si aspetta, all’aumentare del valore di HZ, si riduce l’errore, fino al punto un cui l’errore introdotto dal sistema operativo discusso precedentemente, diventa dominante.
C’ `e da notare che l’effetto della risoluzione del timer dipende dal comportamento delle sorgenti di traffico. Molto spesso, le sorgenti tendono a sincronizzarsi con l’emulatore (ad esempio, un ricevitore TCP risponde immediatamente ai pacchetti rilasciati dall’emulatore) e questo produce il suo effetto nelle misure. Un esem- pio `e in Figura 3.1, in basso, dove `e possibile vedere il ritardo introdotto dalla stessa pipe con delay 10 ms, HZ=1000 e sender sincroni. (in questo caso, unpingcon un intervallo di 10.2 o 10.5 ms, e unping -fche ha una risposta immediata. Come `e possibile vedere, il ritardo di 1 ms non si vede nel test effettuato con un ping -fe nei ping di tipo periodico, dando un caratteristico pattern a gradini.