Overhead dell’emulatore

In dummynet, il costo per processare un pacchetto `e formato da due componenti: la classificazione, che presenta una crescita lineare all’aumentare del numero di regole, e l’emulazione che `e fondamentalmente costante eccetto che per una piccola componenteO(log L)doveLrappresenta il numero delle pipe attive. Le misure riportate nel lavoro [22] evidenziano i vari componenti che fanno parte del costo di elaborazione del pacchetto. I risultati rilevanti di tale lavoro sono riportati in Tabella 3.1.

Le misure sono state effettuate generando il traffico da una sorgente locale, e misurando i pacchetti rice- vuti in vari punti dello stack della rete, come rappresentato in Figura 3.3. Il costo medio di ogni componente (ad esempio qualche istruzione particolare del classificatore, o il costo dell’emulazione. . . ) `e stato calcolato misurando il throughput (in pacchetti per secondo, PPS) in varie condizioni, e calcolando la differenza tra l’inverso dei vari rate in PPS. I valori assoluti dipendono dall’hardware utilizzato, ma il rapporto tra i vari com- ponenti risulta essere costante, indipendentemente dalla piattaforma hardware sul quale vengono eseguiti gli esperimenti.

Costo per pacchetto

La versione del classificatore utilizzata in PlanetLab `e stata estesa con un’ottimizzazione (basata su una tabella di lookup) per poter ricavare velocemente le regole specifiche di un utente. (Paragrafo 2.6).

Utilizzando la stessa tecnica (Figura 3.3) e lo stesso hardware degli esperimenti effettuati nel precedente paragrafo, `e stato misurato il costo per la generazione, (caso A in Table 3.2); e per la generazione e la classificazione di un pacchetto con una sola regola (caso B1); il costo di classificazione utilizzando una

Parameters (from [22]) Cost (ns)

Enter the classifier 400

Test one simple rule 36

Traverse a pipe 700-1300

Overhead for L pipes _{log(L) · 100} New measurements (Sec. 3.2.1) Cost (ns) Table lookup, E entries 220 +_{log(E) · 11} Worst case no pipe, full table < 1000 Worst case 1 pipe, full table 2150 Worst case 20 links/user < 4000

Tabella 3.1: Riepilogo dei costi di emulazione per i vari componenti e costo nel caso di configurazione pi `u onerosa.

infine `e stato calcolato il costo di classificazione utilizzando una tabella piena e l’attraversamento di una pipe nella peggiore configurazione possibile3 (casoC). Questa configurazione risulta essere anche la peggiore per un nodo PlanetLab con il massimo numero di nodi per sliver (216), utilizzando l’emulatore.

In Tabella 3.2 vengono presentati i risultati dell’esperimento, la deviazione media e standard per ogni test eseguito4_{Per gli esperimenti `e stata utilizzata una macchina desktop, nella minima configurazione compati-}

bile con le specifiche di un nodo PlanetLab, in modo tale da essere sicuri di avere per ogni nodo almeno le prestazioni ottenute nei nostri esperimenti.

Case avg/sd (ns) 1 flow

A 1167 / 72.5 Drop before classifier. B1 1525 / 51.2 Drop in first rule.

BT 1750 / 51.5 Table with 1 entry.

BF T 1911 / 60.8 Table with216entries.

C 3311 / 69.4 BT F and worst-case pipe.

Tabella 3.2: Risultati delle misure dell’overhead per pacchetto, eseguiti con diverse configurazioni del classificatore e dell’emulatore.

Partendo da queste misure iniziali, `e stato misurato il costo di ogni componente, e i risultati sono stati riportati in Tabella 3.1. La ricerca nella tabella di lookup richiede circa 220 ns con una singola entry, ma il costo varia in modo logaritmico all’aumentare del numero di entry inserite, e nel caso peggiore (BF T_{− B}1)

richiede solo 400 ns circa.

La differenza tra i casiAeCevidenzia che nella peggior configurazione possibile, l’emulazione consuma circa 2150 ns nel caso di una tabella di lookup piena e una pipe attiva. Considerando che ogni link di emulazione configurato su PlanetLab introduce due regole extra nella parte del ruleset specifica dell’utente, se permettiamo ad ogni utente di creareM link di emulazione, dovremmo aggiungere_{M · 2 · 36}ns a questo tempo, in aggiunta al contributo logaritmicolog(L)dovuto alla presenza di pi `u pipe attive.

In conclusione, la presenza dell’emulatore incrementa il costo di elaborazione per ogni pacchetto per un tempo inferiore a 1µs se il pacchetto non passa attraverso l’emulatore, e inferiore a 4µs se il pacchetto attraversa le pipe di emulazione.

3_{In precedenti lavori `e emerso che il peggior caso in termini di costo per l’emulazione `e la presenza di un link con ritardo}

e nessun limite di banda.

Throughput

Per determinare come l’overhead relativo all’emulazione influisce sulle prestazioni di un nodo PlanetLab, `e stato valutato il carico di rete dei nodi della piattaforma. Lo strumento utilizzato per valutare il carico dei nodi viene fornito dal monitor CoTop [12] reso disponibile dalla piattaforma stessa, CoTop calcola una media del traffico su un nodo su un intervallo di 1 minuto, e il pi `u alto valore rilevato `e stato di circa 30 Mbit/s. CoTop non fornisce il numero di pacchetti per secondo misurati sul nodo, ma il valore rilevato di 30 Mbit/s corrisponde a circa 2500 e 58000 PPS, considerando rispettivamente una dimensione del pacchetto di 1500 e 64 bytes.

Considerando il caso peggiore di un overhead di 4µs per secondo, ad un rate di 60 KPPS avremo su un core CPU, un carico del 25%, che `e un valore accettabile, considerando anche il fatto che stiamo sovrastimando il carico in PPS del nodo di almeno un ordine, e che la maggior parte dei nodi di PlanetLab hanno un carico di rete molto inferiore al massimo considerato.

Costo di riconfigurazione

La parte finale della valutazione delle prestazioni su un nodo PlanetLab ha riguardato il costo di configu- razione di un nodo, cio `e di inserimento, modifica o cancellazione di un link di emulazione.

Sebbene non c’ `e necessit `a di effettuare questo tipo di richieste in modo frequente, essendo PlanetLab un sistema condiviso tra pi `u utenti, si pone il problema della concorrenza, in modo da essere sicuri che anche le operazioni di configurazione non appesantiscano il sistema.

Le riconfigurazioni, effettuate in modo esplicito dagli utenti, comunicano con l’emulatore tramite il sistema vsys, descritto nel Paragrafo 2.4.2, che a sua volta effettua delle chiamate a /sbin/ipfwper aggiornare le pipe e la configurazione del classificatore. I componenti coinvolti nel processo di configurazione sono rappresentati in Figura3.4.

Figura 3.4: Le operazioni coinvolte nella configurazione dell’emulatore.

Per quanto riguarda il backend del servizio vsys, l’attuale struttura memorizza gli utenti collegati in un semplice file di testo e lo manipola tramite un semplice script shell. Con questa versione non ottimizzata l’intero ciclo di configurazione nel backend viene eseguito in meno di 30 ms, che implica che possono essere gestite decine di riconfigurazioni al secondo.

Il costo della riconfigurazione pu `o comunque essere facilmente ridotto di almeno un ordine di grandezza utilizzando una versione compilata del programma di backend.

3.2.2

Accuratezza dell’emulatore

Un aspetto molto importante in un emulatore `e quando accurata sia la riproduzione del modello. Una descrizione dettagliata di questo aspetto `e in [22], dove vengono analizzati tre principali fonti di inaccuratezze:

• il traffico in competizione; • il carico di sistema.

Di seguito analizziamo l’impatto di questi tre fattori nello specifico contesto della piattaforma PlanetLab. La prima fonte di inaccuratezza `e data dalla risoluzione del timer, che su un nodo PlanetLab `e di 1 ms. Questo vuol dire che, a parte la presenza di altre fonti di errore, tutti i pacchetti trasmessi e ricevuti saranno soggetti ad una inaccuratezza relativa al timer di 1 ms. L’obiettivo che ci poniamo `e riuscire a capire se questo errore `e accettabile o meno per la tipologia di esperimenti che vogliamo effettuare, e come confrontare questo errore con gli altri errori introdotti da altri componenti del sistema.

Per quanto riguarda il traffico in competizione sulla rete, anche in assenza di emulazione, dovremo con- siderare anche il tempo massimo di transito per i pacchetti, che sar `a pari alla dimensione massima di un pacchetto per il rate dell’interfaccia. In base alle informazioni riportate dai tool di monitor di PlanetLab, molti nodi dispongono di una connessione tramite switch a 100 Mbit/s nonostante utilizzino delle interfacce di rete al Gbit. Come conseguenza avremo l’introduzione di un errore di almeno 1.2 ms, che risulta essere gi `a pi `u grande di quello introdotto dalla risoluzione del timer.

Infine, la sorgente che introduce una maggiore e non definita inaccuratezza `e il carico per il sistema dovuto alla presenza di stazioni in competizione per l’accesso al mezzo. Questo effetto riguarda sia il kernel (che si trova a dover ritardare l’elaborazione relativa al traffico di rete in caso di CPU occupata) sia la schedu- lazione di altre applicazioni utente, che possono subire dei ritardi (fino a centinaia di millisecondi) da altre applicazioni che utilizzano intensamente la CPU.

Per riuscire a misurare l’influenza del primo componente (il carico del kernel) sono stati effettuati dei test di ping utilizzando coppie di nodi PlanetLab siti nello stesso luogo (colocati). I risultati dei tempi di ping non hanno riportato l’effetto dovuto allo scheduling dei processi utente, questo perch ´e il task predisposto alla risposta esegue interamente in kernel space, e il task che invia inserisce il timestamp nel pacchetto appena esso raggiunge il kernel, quindi le misure non tengono in conto i ritardi relativi allo scheduling.

Anche con queste condizioni abbastanza favorevoli, dalle misure effettuate sui nodi PlanetLab emergono delle variazioni consistenti. In Figura 3.5 sono riportati i grafici della funzione di distribuzione dei tempi di ping tra coppie di nodi PlanetLab colocati. I valori medi nella maggior parte dei casi sono compresi tra 150 e 500 ns, ma quasi sempre `e visibile una coda lunga, con il 5-10% dei valori massimi superiori a diversi millisecondi. In un caso di nodo con molto carico, la curva all’estrema destra nella figura, si possono notare dei ritardi dell’ordine della decina di millisecondi.

Dal queste misure possiamo concludere che, a causa delle applicazioni concorrenti in esecuzione sui nodi e altre attivit `a relative alla rete, l’inaccuratezza introdotta dall’emulazione non `e maggiore delle incertezze sul tempo a cui `e soggetta un’applicazione in esecuzione su un nodo.