TEST PRESTAZIONALI ED OTTIMIZZAZIONE DI UN CLUSTER DI CALCOLO OPENMOSIX


PRESTATIONAL TESTS AND OPTIMIZATION ON A OPENMOSIX CLUSTER

CLICK HERE FOR ENGLISH VERSION

SCOPO DI QUESTO DOCUMENTO

Lo scopo di questo scritto e' la tracciatura dei differenti livelli prestazionali forniti da un cluster di 4 PC, in funzione della topologia di rete con la quale verranno interconnesse le macchine.

A CHI SI RIVOLGE QUESTO DOCUMENTO

Mi rivolgo principalmente a persone che hanno già esperienza con i cluster openMosix (da ora in poi indicato con oM) e che vogliono trarre il massimo vantaggio in termini prestazionali dal proprio cluster.

IL PERCHE' DI QUESTO DOCUMENTO

In tutta la documentazione che ho letto inerente oM, ho notato che l'incremento prestazionale dato dall'aggiunta di nodi ad un cluster e' MENO che proporzionale. Da un documento letto, (si veda la documentazione reperibile nel sito di openmosix) risulta che 24 nodi (identici) non danno come risultato un cluster che 'va' come se fosse un nodo 24 volte piu' veloce, ma SOLO 15 volte piu' veloce... E' come se la potenza di 9 nodi si fosse 'persa per strada'. Un altro documento, parlava di un cluster di 20 desktop Pentium1 a 100Mhz che davano una potenza equivalente di un Pentium1 a 1700Mhz. Ora, nel secondo caso la potenza persa e' giustificabile dal fatto che l'algoritmo di oM richiede tempo per calcolare i carichi dei nodi e decidere di conseguenza la migrazione dei processi; inoltre, altro tempo viene impiegato per la necessità fisica di migrare il processo da un nodo all'altro. Ma nel primo caso si ha una CONSISTENTE perdita di potenza complessiva: questo porta a pensare che sia il TIPO di applicativo e la relativa necessità di traffico di rete a fare la differenza.
Di conseguenza, e' facile dedurre che il guadagno prestazionale del cluster abbia un andamento paraboloide-logaritmico: all'inizio, l'aggiunta di nodi comporta un netto incremento prestazionale, poi mano mano che si aggiungono nodi, la potenza del cluster aumenta sempre di meno, cioe' piu' si aggiungono nodi e meno potenza si guadagna, ottenendo un andamento logaritmico, col quale, l'aggiunta di ulteriori nodi farà aumentare la potenza totale del cluster di una quantità minima, antieconomica rispetto al costo del nodo aggiunto. Uno studio e' in tal senso e' importante in quanto si puo' calcolare quale e' il rapporto prezzo/prestazioni di un cluster in funzione dell'applicativo: non avrebbe senso creare un cluster di 100 PC se poi oltre il 70esimo nodo aggiunto non si avrebbero sostanziali incrementi prestazionali.

Qui di seguito la rappresentazione grafica di quanto sopra detto. 

 
 |
 | Il grafico non e' in scala
 |
p|
o|
t|                                                                 ************
e|                                                *****************    	
n|                                      **********			
z|                                ******             			
a|                             ***                       		
 |                         ****                          		
d|                     ****                       			
i|                  ***                           			
 |               ***                               			
c|             **                               			
a|          ***								
l|        **								
c|      **								
o|    **								
l|   *									
o|  *									
 | *									
 |*									
 |_____________________________________________________________________________
  1 2 3 ........................... Numero nodi ............................. N


Esistono cluster oM di centinaia e migliaia di nodi (il piu' grande di cui ho notizia e' composto da piu' di 2200 nodi) per cui il numero in cui si presenta il picco e' molto al di là del numero dei nodi disponibili all'hobbista, all'utente evoluto o anche alla media industria; tuttavia, perche' lasciare inutilizzata la potenza dei nostri nodi? Vediamo dunque come agire.

DOVE E COME MIGLIORARE IL CLUSTER

Così come le prestazioni totali di un pc sono date da piu' elementi (ram, disco, CPU, scheda video, etc) e la modifica di uno o piu' elementi può aumentare le capacità totali del sistema, così anche un cluster può essere migliorato agendo sugli elementi che lo costituiscono.

Quattro sono i punti su cui agire per migliorare la situazione:

A - l'algoritmo di openMosix
B - l'hardware (CPU, ram, dischi fissi)
C - gli applicativi da eseguire sul cluster
D - le connessioni tra nodi (il numero e velocità delle schede di rete, tipo di connessione, switch, etc)

A - l'algoritmo di openMosix
Qui c'e' poco da fare: l'algoritmo e' di per se' già buono: se un nodo e' disponibile a ricevere processi, NON lo dice a tutti gli altri nodi, ma SOLO a qualche nodo a caso. In tal modo, il nodo libero non viene 'assalito' da tutti gli altri, ma solo da qualche nodo. Questo sistema garantisce un traffico di rete contenuto, assicurando al contempo che dopo un certo periodo il cluster sarà bilanciato, cioe' ogni nodo avrà ricevuto una quantità di processi omogenea al carico degli altri nodi ed alla propria capacità computazionale.

B - l'hardware
Qui la soluzione e' banale: incrementi di RAM e/o CPU dei nodi si riflette in automatico sulle capacità finali del cluster.

C - gli applicativi
Questo e' un argomento vasto: ovviamente, un cluster in cui gira UN solo processo e' INUTILE, la potenzialità del cluster risulta evidente quando ci sono decine/centinaia di processi attivi, che impegnano al massimo la capacità elaborativa dei nodi. Tanti piccoli processi (idealmente, uno per ogni nodo, così da minimizzare le comunicazioni di rete e massimizzare l'utilizzo di un nodo) verranno elaborati piu' velocemente di pochi grossi processi. Qui sta alla capacità ed all'esperienza degli utilizzatori su come implementare i propri software.
Se siete degli sviluppatori, prendete in considerazione l'idea di scrivere software che esegua dei 'fork' in modo da parallelizzare su piu' processi il proprio carico di lavoro. Se siete un utente finale, cercate di procurarvi un software che esegua dei 'fork', oppure lanciate molti istanze dello stesso processo su blocchi di dati piuttosto che lanciare un unico processo sull'intero insieme di dati da elaborare: per esempio, al posto di lanciare un processo che calcola la radice quadrata dei numeri che vanno da 1 a un miliardo, lanciate 4 processi che eseguano lo stesso calcolo per blocchi di numeri da 1 a 250 milioni, da 250 a 500 milioni e così via fino ad un miliardo. In questo modo ci saranno 4 processi distinti che potranno essere migrati sui vari nodi del cluster.

D - le connessioni tra i nodi
In questo documento, ci concentreremo sul punto D in quanto e' la parte che vogliamo migliorare: da adesso in poi, la sceda di rete verra' indicata con la sigla NIC (Network Interface Card).

I NODI DEL CLUSTER
L'hardware disponibile e' il seguente:

4 nodi desktop IBM 300GL
CPU: P2 300Mhz
RAM: 64M a 66Mhz
NIC: 10/100 3com 3c905*

Sono stati scelti PC tutti uguali in quanto risulta piu' facile eseguire dei test su hardware omogeneo: questo permetterà di dire che:

"un cluster di TOT PC con CPU a ZMhz connessi in topologia Y equivale ad un unico PC di Whz quando svolge il compito T".

In questo documento ci preoccuperemo di dare dei valori alle variabili TOT, Z, Y, W e T :-).

PREREQUISITI
Questo documento e' la prosecuzione ideale di quello precedente, dove si spiega come realizzare un cluster con (fino a) 8 nodi. Questo cluster si presuppone già configurato ed attivo, composto da 4 nodi e si dà per scontato quanto segue:

- che i 4 nodi abbiano questa configurazione: 



NODO   NOME      INDIRIZZO IP	 FUNZIONE
 A    server     192.168.1.1	 server
 B    nodo2      192.168.1.2	 nodo slave
 C    nodo3      192.168.1.3	 nodo slave
 D    nodo4      192.168.1.4	 nodo slave
- che tutti i nodi abbiano lo STESSO kernel e la stessa configurazione di cluster (con il MFS=yes)
- che i nodi slave abbiano il solo compito di fornire potenza di calcolo al master, ma che non abbiano altri carichi di lavoro (es: niente KDE o Gnome)
- che, se necessaria, l'interfaccia grafica KDE sia presente solo sul nodo master
- che su tutti i nodi sia installato ssh in modo da permetterne una facile manutenzione anche senza passare dal file-system di oM.
- che il cluster sia gia' configurato e funzionante per lavorare tramite hub/switch: nel caso sia necessario, fate riferimento al documento inerente la creazione di un cluster.

COME VERRANNO CABLATI I NODI DEL CLUSTER

Verranno provate varie topologie di rete, onde determinare il rapporto prezzo/prestazioni di ognuna di esse anche in funzione dell'applicativo testato.

TOPOLOGIE A CONFRONTO
Lo schema successivo verrà popolato con in risultati che produrremo man mano, per essere poi commentati alla fine di questo documento. 

    +----+-----+-----------+--------------+----+---------+------+
    |    |     |           | bladeenc     |    |         |      |
    |N°  |N° pc|tipo di    | tempo  tempo |num.| tipo di |schede|
    |caso|usati|connessione| mm.ss  in %  |cavi| cavo    |totali|
    +----+-----+-----------+--------------+----+---------+------+
    |  1 |  1  |    -      | mm.ss  100.00|  0 |    -    |   0  |
    |  2 |  4  |hub 10     | mm.ss  xxx.xx|  4 | diretto |   4  |
    |  3 |  4  |switch 100 | mm.ss  xxx.xx|  4 | diretto |   4  |
    |  4 |  4  |P2P        | mm.ss  xxx.xx|  3 | incroc. |   6  |
    +----+-----+-----------+--------------+----+---------+------+

Verranno eseguite prove su queste 3 tipologie differenti onde verificare il guadagno prestazionale nei vari casi, il test numero uno sarà fatto per avere una pietra di paragone con la quale confrontare tutti i risultati successivi. Ovviamente, le configurazioni piu' "interessante" sara' l'ultima, dove il cluster sara' ottimizzato a livello di topologia di rete.

Ecco degli esempi grafici di vari tipi di connessione: 

        CASO 2			CASO 3	 	        CASO 4
   +---------------+       +---------------+       +---------------+
   |               |       |               |       |    server     |
   |      hub      |       |    switch     |       |   e   e   e   |
   |    10Mbit/s   |       |   100Mbit/s   |       |   t   t   t   |
   |               |       |               |       |   h   h   h   |
   |               |       |               |       |   0   1   2   |
   +---------------+       +---------------+       +---------------+
     |   |   |   |           |   |   |   |             |   |   |  	
     |   |   |   |           |   |   |   |             |   |   |   	
     |   |   |   |           |   |   |   |             |   |   |	
     |   |   |   |           |   |   |   |             |   |   |  	
    .-. .-. .-. .-.         .-. .-. .-. .-.           .-. .-. .-.	
    |s| |n| |n| |n|         |s| |n| |n| |n|           |n| |n| |n|	
    |e| |o| |o| |o|         |e| |o| |o| |o|           |o| |o| |o|	
    |r| |d| |d| |d|         |r| |d| |d| |d|           |d| |d| |d|	
    |v| |o| |o| |o|         |v| |o| |o| |o|           |o| |o| |o|	
    |e| |2| |3| |4|         |e| |2| |3| |4|           |2| |3| |4|	
    |r| :_: :_: :_:         |r| :_: :_: :_:           :_: :_: :_:	
    :_:                     :_:


SVANTAGGI DEL CASO 4

- Detto N il numero dei nodi del cluster, servono 2*(N-1) NIC, N-1 sul server e poi una per ogni nodo. Quindi il numero delle NIC cresce in modo quasi doppio rispetto al numero dei nodi.

- Si perde in flessibilita' nel cluster in quanto:

- A) il server deve essere istruito su come instadare i pacchetti
- B) I nodi sono dedicati quasi esclusivamente a fornire potenza di calcolo, in quanto il server "vede" tutti i nodi, ma il singolo nodo "vede" solo il server.
- C) I processi devono essere lanciati dal server (in realta' questo problema puo' essere eliminato usando ssh per controllare in remoto il server).
- D) C'e' un limite fisico all'aumento del numero dei nodi, e questo limite e' dato dal numero di slot PCI presenti sul server. Ho visto in commercio delle piastre madri con 7 slot PCI e NIC integrata, per cui si potrebbe fare un cluster da 9 nodi P2P, con la sola necessita' di 7 NIC aggiuntive


VANTAGGI DEL CASO 4
- La connessione punto-punto ottimizza la velocita' di comunicazione tra il server e i nodi, per cui si dovrebbe accellerare la trasmissione dati via rete: se si e di quanto, e' da vedere; ecco perche' sto scrivendo questo documento :-).

PREPARIAMO IL SERVER
Nella nostra (spasmodica) ricerca di colli di bottiglia da ottimizzare, ci scontriamo col server, o meglio, con l'hard disk del server. Infatti, quest' ultimo dovra' reggere tutto il carico di I/O del files. Come vedremo in seguito, questo carico sara' pesante, per cui non avrebbe senso ottimizzare la velocita' di rete se poi non abbiamo abbastanza dati da farci transitare. L'hard disk originale (hda) non e' quello che si dice un fulmine: dal test effettuato con hdparm -t /dev/hda otteniamo un valore di 12.36MB/sec. aggiungiamo percio' un hard disk piu moderno, e lo montiamo come hdc. Il risultato di hdparm -t /dev/hdc e' un piu' confortante 28.83MB/sec.
Potremmo aumentare la velocita' di I/O facendo in modo di avere i file sorgenti su hdc e i file destinazione sul disco hda, in modo da sfruttare al meglio la banda dei due controller EIDE. Certo, sarebbe stato meglio avere dei dischi SCSI, ma, come detto, stiamo lavorando in economia con materiale di riciclo per cui bisogna accontentarsi :-|

OTTIMIZZIAMO L'HARD DISK

Prima di cominciare ad eseguire le prove, occorre considerare che l'hard disk del nodo master, tranne che nel CASO 1, sara' sottoposto ad un pesante traffico di I/O in quanto verranno letti in parallelo i file sorgenti e verranno altresi' scritti i file convertiti. Occorre perciò assicurarci che l'hard disk non diventi un "collo di bottiglia" che rallenti il cluster. Il comando 'hdparm' permetterà di migliorare le prestazioni dell'hard disk (man hdparm per i dettagli). Comunque, il minimo indispensabile lo indico subito; se l'hard disk sul quale operiamo e' hdc, il comando 
# hdparm -c 1 -d 1 /dev/hdc
attiverà l'I/O a 32bit e l'utilizzo del DMA.


SOFTWARE DI TEST UTILIZZATO

Il software utilizzato e' bladeenc, un programma a riga di comando per la conversione tra vari formati audio. Verra' usato per convertire molti file (tramite script) da WAV a MP3 e 'stressare' le connessioni tra i nodi. Il programma l'ho scaricato dal sito http://bladeenc.mp3.no. Poiche' uso DEBIAN, ho utilizzato il relativo pacchetto .deb gia' compilato per Pentium 1 o CPU superiore.

Se voi non utilizzerete un software che genera un grosso carico di rete, il beneficio che otterrete dalla topologia che implementeremo potrebbe essere modesto o addirittura nullo. Resta il fatto che il cluster sarà in grado di supportare un elevato traffico di rete qualora ce ne fosse bisogno.

CONFIGURAZIONE PER HUB E SWITCH

Questi file sono validi per i casi 1, 2, e 3. Per il caso 4, verrà specificato in dettaglio come sono stati configurati i vari file.

/etc/openmosix.map (valido per tutti i nodi) 
        1 192.168.1.1 1
        2 192.168.1.2 1
        3 192.168.1.3 1
        4 192.168.1.4 1
/etc/default/openmosix (valido per tutti i nodi) 
        # This node is a Mosix node.
        OPENMOSIX_NODE=yes
        # Processes are allowed to migrate to other nodes.
        MIGRATE=yes
        # Allow guest processes to arrive.
        BLOCK=no
        # use of MFS (Mosix File System)
        MFS=yes
        #EOF#
/etc/hosts (server) 
        192.168.1.1     server
        127.0.0.1       localhost
/etc/hosts (nodo 2) 
        192.168.1.2     nodo2
        127.0.0.1       localhost
/etc/hosts (nodo 3) 
        192.168.1.3     nodo3
        127.0.0.1       localhost
/etc/hosts (nodo 4) 
        192.168.1.4     nodo4
        127.0.0.1       localhost


I FILE DI TEST
Montiamo hdc1 (la partizione che contiene i file) su /mnt/hdc1. La directory che contiene il programma bladeenc e tutti i file e dall'interno della quale si agirà e' /mfs/0/mnt/hdc1/. La directory contiene 24 file audio in formato WAV che verranno convertiti in formato MP3. In realtà i 24 file audio sono lo stesso file clonato 23 volte: questo per fare in modo che ogni file occupi la CPU allo stesso modo di tutti gli altri, per avere dei risultati il piu' omogenei possibili.
Per minimizzare le differenze tra un test e l'altro, occorre cancellare i file creati audio*.mp3 e audio*.txt creati durante i vari test.

SCRIPT DI TEST

Per ottimizzare le prestazioni, verranno usati due script diversi, uno per il caso iniziale (il solo nodo master) e uno script che verrà usato in tutti gli altri casi.

SCRIPT PER IL SOLO MASTER

Disabilitate il clustering con:

/etc/init.d/openmosix stop

in modo da isolare il master dagli altri nodi. Ora occupiamoci dello script.
Questo script serve per vedere quanto tempo impiega un singolo nodo per completare la conversione di tutti i file. In questo modo, avremo disponibile un dato con cui confrontare tutti i risultati che seguiranno.
Il contenuto dello script di conversione (che si chiama converti.sh) e' il seguente: 
    #!/bin/sh
    date +%s > /mfs/0/mnt/hdc1/audio.txt
    ./bladeenc -quit -quiet audio01.wav -256 -copy -crc
    ./bladeenc -quit -quiet audio02.wav -256 -copy -crc
    .........................................
    ./bladeenc -quit -quiet audio23.wav -256 -copy -crc
    ./bladeenc -quit -quiet audio24.wav -256 -copy -crc
    date +%s >> /mfs/0/mnt/hdc1/audio.txt

In questo caso, poiche' il pc master sta lavorando da solo, le 24 istanze di bladeenc sono state lanciate una dopo l'altra, per mitigare l'intervento dell' algoritmo di linux che gestisce il multitasking intervenga a gestire (e rallentare) l'esecuzione dei vari processi: in questo modo lo script viene visto come un solo processo e gestito piu' velocemente.
Lo script (tramite i due comandi 'date') genera il file /mfs/0/home/mnt/hdc1/date.txt il quale contiene due numeri, la cui differenza darà la durata, in secondi, dello script.

SCRIPT PER IL CLUSTER
il contenuto dello script di conversione (che si chiama converti-om.sh) e' il seguente: 
    #!/bin/sh
    ./converti01.sh &
    ./converti02.sh &
    ...............
    ./converti23.sh &
    ./converti24.sh &

In questo modo, lo script 'converti-om.sh' lancia in background (grazie al parametro '&') i 24 script che, venendo considerati 'atomici', possono migrare tra i vari nodi del cluster.
Devono essere creati 24 script chiamati 'convertiXX.sh' dove XX varia da 01 a 24. Il contenuto dei singoli script deve essere il seguente: 
date +%s > audioXX.txt ; bladeenc -quit -quiet audioXX.wav -256 -copy -crc ; date +%s >> audioXX.txt
anche qui XX deve andare da '01' a '24'.
Gli script sono composti da tre comandi distinti: il primo comando 'date' scrive all'interno del file di report audioXX.txt il tempo in secondi di quando lo script e' partito; il comando 'bladeenc' converte il file audioXX.wav in audioXX.mp3 ed infine l'ultimo comando 'date' scrive, in secondi, il momento in cui lo script termina.
I due comandi 'date' servono solo per registrare il momento di inizio e di fine della conversione: dalla differenza dei due numeri riportati all'interno del file audioXX.txt si avrà la durata in secondi del processo di conversione.
confrontando le 24 durate, quella piu' grande indicherà il tempo impiegato complessivamente dal cluster per portare a termine tutte e 24 le conversioni.


INIZIAMO I TEST
Tutti i test vanno lanciati dal nodo master.

NOTA: per motivi esterni, non ho potuto utilizzare 4 nodi, ma solo 3, cioe' server + nodo02 + nodo03 per cui, riportero' i dati del lavoro del cluster a 3 nodi, anche se vedrete scritto che i nodi sono 4.

CASO 1: test sul nodo master senza connessioni ad altri PC (dettaglio)
Lanciate il comando ./converti.sh, (aspettate la conclusione) editate il file audio.txt, calcolate la differenza e scrivetela in tabella.

CASI 2, e 3: HUB E SWITCH
L'implementazione dei casi 2 e 3 e' banale in quanto si tratta di collegare tutti i pc, scegliendo di volta in volta il mezzo di connessione hub e switch, eseguire i test e riportarne in tabella i risultati. Ovviamente qui oM DEVE essere attivato, per smistare i processi tra i vari nodi.

CASO 4: TOPOLOGIA P2P
Piu' complesso e' l'ultimo caso dove occorre attivare sul server piu' di una NIC.
Ora entriamo nel vivo di questa serie di test, cioe' verificheremo se e quanto sarà l'incremento prestazionale del cluster in funzione dell'aumentare delle NIC attive, e di conseguenza la velocità di connessione tra i nodi. 


    	    P2P A QUATTRO NODI
                               
	+-----------------------+	
	|                       |
	|          server       |
	|                       |	
	|    e      e      e    |	
	|    t      t      t    |	
	|    h      h      h    |	
	|    0      1      2    |	
	+-----------------------+	
             |      |      |
             |      |      |
             |      |      |
             |      |      |
           .- -.  .- -.  .- -.
           |   |  |   |  |   |
           | N |  | N |  | N |
           | o |  | o |  | o |
           | d |  | d |  | d |
           | o |  | o |  | o |
           | 2 |  | 3 |  | 4 |
           :___:  :___:  :___:
              
	      Nodo.punto_rete <-> Nodo.punto_rete
                  Server.eth0 <-> nodo2.eth0 
                  Server.eth1 <-> nodo3.eth0  
                  Server.eth2 <-> nodo4.eth0
Ora occorre attivare tutte le NIC del server, istruendole in modo da instradare il traffico di rete in modo "intelligente" verso gli altri nodi.
Contrariamente a quanto si potrebbe immaginare, NON e' necessario dedicare un indirizzo di rete ad ogni NIC del nodo, ma e' possibile (grazie al kernel 2.4.x o superiore) condividere lo stesso indirizzo IP su tutte le NIC del nodo.

Indico di seguito in contenuto dei file /etc/network/interface presenti sui 4 nodi.


Nodo A (Server) 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    up route add -host 192.168.1.2 dev eth0
auto eth1
iface eth1 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    up route add -host 192.168.1.3 dev eth1
auto eth2
iface eth2 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    up route add -host 192.168.1.4 dev eth2

Nodo 2 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 192.168.1.2
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255

Nodo 3 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 192.168.1.3
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255

Nodo 4 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 192.168.1.4
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255


Esaminiamo con attenzione la configurazione (per esempio) del punto_rete eth0 del server: 
auto eth0
iface eth0 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    up route add -host 192.168.1.2 dev eth0
Le prime sei righe sono facilmente comprensibili, mentre l'ultima e' l'istruzione "magica": infatti traducendola in italiano significa: "tutte e solo le comunicazioni che dall'IP corrente (192.168.1.1) e che sono diretti all'IP 192.168.1.2 devono essere instradate sulla NIC fisica chiamata eth0". In questo modo non avvengono collisioni superflue in quando si tratta di una connessione peer-to-peer cioe', in italiano , punto-a-punto: in breve P2P.

ANALISI DEI RISULTATI

i file di partenza sono lunghi 89782940 byte e generano file lunghi 16287870 byte.

facendo qualche conto, circa 2426MB sono movimentati sulla rete. Come anticipato, riempiamo la tabella che precedentemente preparata: inoltre, e' presente anche una rappresentazione semigrafica, per facilitare la lettura dei risultati:

    +----+-----+-----------+--------------+----+---------+------+
    |    |     |           | bladeenc     |    |         |      |
    |N°  |N° pc|tipo di    | tempo  tempo |num.| tipo di |schede|
    |caso|usati|connessione| mm.ss  in %  |cavi| cavo    |totali|
    +----+-----+-----------+--------------+----+---------+------+
    |  1 |  1  |    -      |107.39  100.00|  0 |    -    |   0  |
    |  2 |  4  |hub 10     | 41.12   38.27|  4 | diretto |   4  |
    |  3 |  4  |switch 100 | 39.28   36.66|  4 | diretto |   4  |
    |  4 |  4  |P2P        | 37.40   34.98|  3 | incroc. |   6  |
    +----+-----+-----------+--------------+----+---------+------+

Per completezza, indico per i casi 2, 3 e 4, i job piu' lento e piu' veloce per dare una idea della omogeneita' dei dati .

TIPO		LENTO	VELOCE	DIFF	DIFF%
hub10MB/s	41m12s  39m01s  2m11s    5.3%
switch		39m28s  38m58s  0m31s    1.3%
P2P		37m40s  36m44s  0m56s    2.5% 


num  tipo  CASO         20%       40%       60%       80%       100%
pc   conn.         10%   |   30%   |   50%   |   70%   |   90%   |
                    v    v    v    v    v    v    v    v    v    v
 1     -     1  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 100.00%
 2  hub10    2  OOOOOOOOOOOOOOOOOOO.    |    |    |    |    |    |  38.27%
 3  sw100    3  OOOOOOOOOOOOOOOOOOo|    |    |    |    |    |    |  36.66%
 4  P2P      4  OOOOOOOOOOOOOOOOOo |    |    |    |    |    |    |  34.98%
                -------------------------------------------------- 
                Tempo in percentuale rispetto al singolo pc.


Perche' nei casi 2, 3 e 4 le prestazioni sono sostanzialmente simili? Non era quello che ci si aspettava.

TEST VELOCITA' DI COMUNICAZIONE TRA I NODI

Verifichiamo quale e' la velocita' di comunicazione tra due nodi, nei casi 2, 3 e 4: per farlo, copieremo un file di 320M dal server al nodo due, calcolando i tempi e modificando caso per caso la connessione. Creiamo un file di 32M:

dd if=/proc/kcore of=pippo bs=1k cout=32768

Usiamolo per creare un file 10 volte piu' grande

cat pippo pippo pippo pippo pippo pippo pippo pippo pippo pippo > prova

Per la cronaca, il file prova risulta essere lungo 334455320 Byte, ossia esattamente 320M.

copiamo il file prova dal server al nodo02:

time cp prova /mfs/2/root

Questo comando deve essere ripetuto tre volte: con connessione hub, switch e P2P, rispettivamente: (ricordatevi di modificare il file /etc/network/interfaces sul nodo server) riporto qui i risultati. 

CONNESSIONE		TEMPO (s)	PERCENTUALE	MB/s
hub 10Mbs	   	337.4	     	100.0%		0.95
switch 10/100Mbs	453.3	     	134.3%		0.70
P2P		    	 71.5      	 21.2%		4.47


Lo switch 10/100Mb/s ha dato un risultato peggiore dell'hub: in questo caso, l'uso dello switch si e' rivelata controproducente.

Come si vede, la connessione P2P e' la migliore, dal punto di vista della velocita' di trasferimento dati. Perche' allora, il cluster non ne ha tratto giovamento?
Evidentemente, per questo cluster, la velocita' di rete NON rappresenta un collo di bottiglia.
Appare ovvio che il collo di bottiglia e' altrove: se rilancio i test 2 e 3, monitorando il traffico di rete con iptraf, vedo che (nei casi 2 e 3) la velocita' della NIC si attesta sui 750-830KB/s. Tale valore e' tranquillamente gestibile sia dall'hub che dallo switch.

Dov'e' il collo di bottiglia, allora? Il problema e' nella CPU del nodi, che non possono elaborare un flusso di dati sufficentemente grande da saturare le connessioni nei casi 2 e 3.

Occorrerebbero piu' nodi e/o nodi piu' potenti, tipo P3/P4, ma non dispongo di tale hardware.... Che fare allora? posso tentare di rendere meno pesante l'algoritmo di conversione audio, in modo da accellerare il flusso dati, aumentando cosi' il carico di rete. per fare questo, modifico gli script di conversione in questo modo: 
date +%s > audioXX.txt ; bladeenc -quit -quiet audioXX.wav -256 -mono ; date +%s >> audioXX.txt
Cosi' la conversione sara' mono e non piu' stereo, dimezzando i tempi di conversione.
Ecco i risultati:



    TIPO          LENTO       VELOCE       DIFF    DIFF%
    hub10MB/s     28m29s      21m10s       7m18s   25.7%
    switch        25m56s      12m04s      13m52s   53.5%
    P2P           19m42s      17m38s       2m04s   10.5%


E' interessante notare che, nel caso dello switch, c'e' una notevolissima discrepanza tra la durata dei job piu' lento e piu' veloce. su 24, ce ne sono stati 3 di durata inferiore ai 14 minuti.

Ora siamo in grado di dare dei valori a quelle famose incognite X,Y, Z, T e W.

La frase che inizialmente era: "un cluster di 4 PC con CPU a ZMhz connessi in topologia Y equivale ad un unico PC di Whz quando svolge il compito T".

Diventa:
"un cluster di 3 PC con CPU Pentium 2 a 300Mhz connessi in topologia Y equivale ad un unico PC di WMhz quando svolge il 24 job di conversione audio".

Restano da definire i valori Y (topologia) e W (Mhz).
Tali valori sono (dopo che ho rifatto tutti i test) ricavabili da questa tabella: 
   tipo  CASO          20%       40%       60%       80%       100%
   conn.          10%   |   30%   |   50%   |   70%   |   90%   |
                   v    v    v    v    v    v    v    v    v    v
     -      1  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 100.00% 53m53s
   hub10    2  OOOOOOOOOOOOOOOOOOOOOOOOOOo  |    |    |    |    |  52.86% 28m29s
   sw100    3  OOOOOOOOOOOOOOOOOOOOOOOO|    |    |    |    |    |  48.13% 25m56s
   P2P      4  OOOOOOOOOOOOOOOOOOo|    |    |    |    |    |    |  36.56% 19m42s
               -------------------------------------------------- 
               Tempo in percentuale rispetto al singolo pc.
Notate come nel caso P2P il tempo in percentuale (36.56%) sia molto vicino al massimo teorico (33.33%) con uno scarto di solo il 3.23%


Le variabili Y e W assumono ora questi valori:


   numero   Topologia	 Potenza equiv.    Max. potenza      differenza
   PC       (Y)          (W)                teorica
   1        -            300Mhz            -
   3        hub          567Mhz            900Mhz            -36.94%
   3        switch       623Mhz            900Mhz            -30.74%
   3        P2P          820Mhz            900Mhz            - 8.88%
Aggregando tre CPU da 300Mhz, ci si potrebbe aspettare, al massimo, di avere un potenza complessiva pari ad una CPU virtuale a 900Mhz: in questo caso, abbiamo come risultato 820Mhz, cioe' una discrepanza di poco meno di 9 punti percentuali rispetto al massimo teorico. Abbiamo visto che c'e' un evidente e convenienete incremento prestazionale, dato unicamente dalla topologia: il cluster "scala" bene, il che giustifica e ricompensa ampiamente gi svantaggi del P2P.

 tipo  CASO         20%       40%       60%       80%       100%
 conn.         10%   |   30%   |   50%   |   70%   |   90%   |
                v    v    v    v    v    v    v    v    v    v
hub10    2  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 100.00% 28m29s
sw100    3  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOo   |  91.04% 25m56s
P2P      4  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOo|    |    |    |  69.16% 19m42s
            -------------------------------------------------- 
            Tempo in percentuale rispetto alla topologia hub10Mb/s

Analiziamo il comportamento della topologia di rete, ponendo uguale al 100% la velocita' del piu' lento (hub10Mb/s)

Arrotondando i valori, vediamo che il P2P guadagna il 20% rispetto allo switch ed il 30% rispetto all'hub.

Poiche' in una situazione reale sarebbe piu' prevedibile l'utilizzo di uno switch al posto di un semplice hub, possiamo avere questo confronto

 tipo  CASO         20%       40%       60%       80%       100%
 conn.         10%   |   30%   |   50%   |   70%   |   90%   |
                v    v    v    v    v    v    v    v    v    v
sw100    3  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 100.00% 25m56s
P2P      4  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO |    |    |  75.96% 19m42s
            -------------------------------------------------- 
            Tempo in percentuale rispetto alla topologia switch 10/100Mb/s

In questo caso, il guadagno e' del 24%


ULTERIORI SVILUPPI: PREVISIONI PRESTAZIONI

E' interessante notare che basandosi su questa tabella 

   numero	Topologia	 Potenza equiv.    Max. potenza      differenza
   PC    	(Y)          (W)                teorica
   1        -            300Mhz            -
   3        hub          567Mhz            900Mhz            -36.94%
   3        switch       623Mhz            900Mhz            -30.74%
   3        P2P          820Mhz            900Mhz            - 8.88%
si puo' precalcolare la potenza teorica totale generabile dall'aggiunta di altri nodi: 3 nodi->820Mhz, 4 nodi->1095Mhz. Poiche' il P2P ha eliminato il collo di bottiglia dato dalla la velocita' di rete, la potenza risultante da 4 nodi deve essere intesa come "non meno di" 1095Mhz. Mi sarebbe piaciuto avere abbastanza computer per eseguire dei test e comporre la "curva prestazionale" data da Numero_pc/Potenza_equivalente.... forse, lo faro' in futuro :-)

ULTERIORI SVILUPPI: CUSTER P2P PIU' GRANDI DI 9 NODI

Poiche' il server deve "vedere" ogni nodo su una diversa NIC, abbiamo precedentente detto che il numero massimo di quest'ultime equivaleva al numero massimo di nodi del cluster, ma questo non e' del tutto esatto.

Infatti, esistono in commercio NIC che consentono DUE punti rete: in pratica, hanno raddoppiato i chipset di gestione rete su un'unico circuito stampato. Non ho ancora avuto la possibilita' di usarle, ma se funzionassero come le normali NIC, questo consentirebbe di arrivare a cluster da 16 nodi (7 slot PCI * 2 NIC + 1 NIC integrata + il server).

Alternativamente, esiste anche un'altra possibilita': si potrebbero configurare due sotto-cluster in P2P collegati da NIC da 1Gb/s oppure da due o tre NIC con velocita' di rete aggregata tramite channel bonding. Come al solito, la carenza di hardware omogeneo (leggi: pc uguali) mi impedesce di eseguire i relativi test: forse, in futuro riusciro' a produrre dei test adeguati.

CONCLUSIONI

Abbiamo dimostrato che un cluster,

- SE opportunamente configurato,
- E quando esegue job richiedenti massicci scambi di dati tra i nodi

- PUO' sensibilmente aumentare le proprie capacita' elaborative, semplicemente agendo sulla topologia di rete ed a costo di un quasi raddoppio delle NIC utilizzate.

In altre parole, il P2P esprime il massimo delle potenzialita' nel caso in cui ci siano grosse masse di dati da elaborare e la velocita' di rete rappresenta un collo di bottiglia da eliminare, o, quantomeno, ridurre.

NICE TO HAVE

Mi sarebbe piaciuto avere dell'hardware piu' numeroso e/o piu' prestante: 10 o 12 P3 a 1Ghz di clock con 256Mram (adesso, febbraio 2004, tale hardware e' cosiderabile di livello medio/basso) per fare delle prove piu' accurate... Magari, potete farle voi: oppure, se mi procurate i PC, lo faro' io :-)


CREDITS

Questo documento nasce da una mia idea personale.
Ringrazio:
- un socio openlabs (del quale al momento non ricordo il nome) per l'introduzione dell'istruzione
up route add -host 192.168.1.X dev ethY ,

Ma sopratutto, ringrazio me stesso per la caparbieta' dimostrata nel perseguire l'obbiettivo di realizzare questo documento, (troppo a lungo posticipato per la mancanza di hardware a disposizione), anche perche' mi sono fatto un mazzo cosi': bravo Roby!


NOTIZIE SULL'AUTORE

Sono contattabile all'indirizzo di posta elettronica:

roberto.premoli(chiocciola)tiscali.it
oppure
r00(chiocciola)excite.it

ENGLISH VERSION

PRESTATIONAL TESTS ON A OPENMOSIX CLUSTER

SCOPE OF THIS PAPER

Scope of this paper is to take track of different level of prestations of a cluster of 4 nodes , in function of network topology.

DESTINATARY OF THIS PAPER

This paper is for people already able to turn on a openMosix (from hereinafter oM) cluster and that needs to get maximum level of prestations from their own cluster.

WHY THIS PAPER

I read several papers about openMosix: I saw that the improvement of prestations doesn't grow in linear mode in function of added nodes. In a document, I saw that (look at openMosix documentation website) cluster of 24 identical nodes the total power was only fifteen times the power of a single node: it seems as the power of nine nodes gone 'lost in the wind'. In another document 20 Pentium1 at 100Mhz, gave a cluster as a virtual Pentium1 at 1700Mhz. Well, in first case, it is not admissible to loose a so CONSISTENT power quantity: this situation make me to think that is the TYPE of application and the necessity of traffic network that make the difference.
We can see that the power growing of a cluster is parabolic-logarithmic: in other words, more nodes we add, less total power we get. To study this situation is good, because we can calculate the ratio costs/results of a cluster in function of the software that we run on the cluster: it will be a nonsense to build up a 100 node cluster if we will have not power improvement after 70th node added.

Here a graphic representation of here above I said. 

 
 |
 | The graphic in not in scale
 |
p|
o|
w|                                                                 ************
e|                                                *****************    	
r|                                      **********			
 |                                ******             			
o|                             ***                       		
f|                         ****                          		
 |                     ****                       			
c|                  ***                           			
a|               ***                               			
l|             **                               			
c|          ***								
u|        **								
l|      **								
a|    **								
t|   *									
i|  *									
o| *									
n|*									
 |_____________________________________________________________________________
  1 2 3 ........................... Number of nodes ......................... N


There are cluster with thousands of nodes (biggest I know as more than 2200 nodes): thousands of nodes in more than the maximum number of nodes allowed to the hobbyist or the medium firm: overall, why we have to taken not optimized our cluster? Let we see how no work, now.

WHERE AND HOW OPTIMIZE THE CLUSTER

So as the average prestations of a pc came from a variety of different elements (ram, hard disk, CPU, graphic card, etc) and modify a single element can improve the global performances of the PC, in the same way a cluster can be optimized working on the single cluster's elements.

There are four points where were we can work to improve the cluster:

A - the openMosix algorithm
B - the hardware: CPU, ram, etc
C - the software that run on the cluster
D - the connection between nodes: quantity and velocity on Network Interface Card (from hereinafter named NIC), connection type, etc

A - openMosix algorithm
nothing to say: openMosix algorithm is already good: if a node can receive jobs to process, it does not communicate his availability to all the other nodes, but only to a random number of node: this mechanism avoid that a free node will be 'assaulted' by all the other busy node. This system allow a low network traffic and at the same time allows a good load balancing after some time.

B - The hardware
Here is easy: more RAM and/or bigger CPU on the nodes give more power to single node and consequently to the cluster.

C - The jobs
This is a big field: of course, a cluster that runs only ONE job is USELESS: the power of a cluster is clear when there are dozens/hundreds jobs, that use the totality the cluster's power capacity. A lot of little jobs (ideal is one job for one node: this allows to minimize the network delay) will be completed faster than few big jobs. Here is the user's experience that make the difference :-).
If you are developers, take in count to write software that forks. If you are end users, search for software that forks: alternately, run the same software on different data sets to elaborate: i.e. instead to lunch a single job that calculate the square root from 1 to 1 billion, run 4 jobs on 4 set of data: from 1 to 250 million, from 250million+1 to 500million and so on till 1 billion. In this way, you will have 4 independent jobs able to migrate on different nodes.

D - Connection between nodes
In this howto I focused on 'D' point, because I want optimize the network connection.

THE NODES OF CLUSTER
I will work with this hardware:

4 desktop IBM 300GL
CPU: Pentium 2 at 300Mhz
RAM: 64M at 66Mhz
NIC: 10/100 3com 3c905*

I choose identical PCs because it is easier to test hardware of the same nature: this will allow to say that:

"a cluster of TOT PC with CPU at ZMhz connected with topology Y equivalent to a single 'virtual' PC running at Whz when he does the job T".

In this howto I will provide to give a value to TOT, Z, Y, W e T :-).

PRECONDITIONS
This howto is the ideal procecution of a my previous howto where I explained how to build up a cluster with (till) 8 nodes. This cluster is intended as 'up and running' with 4 nodes and with the follow:

- the 4 nodes have this configuration: 



NODE  NAME   IP ADDRESS     FUNCTION
 A    server 192.168.1.1    server
 B    nodo2  192.168.1.2    slave node
 C    nodo3  192.168.1.3    slave node
 D    nodo4  192.168.1.4    slave node
- all the nodes have the SAME kernel and the same cluster configuration (with MFS=yes)
- all the slave node have only to give 'power computation' to the cluster: the nodes have not to run other jobs (i.e.: neither KDE nor Gnome)
- If it will be needed, window manager KDE runs only on the master node
- ssh is installed on every nodes to allow remote control without use openMosix file-system (mfs).
- the cluster is already configured to work with hub/switch.

HOW THE NODES WILL BE CONNECTED

Some different network topologies will be tested, to calculate the cost/benefit ratio, as a function of the used software application.

TOPOLOGIES COMPARATION
This scheme will be filled with the results we will get from the tests: we will comment it at the end of this paper. 

    +----+-----+-----------+--------------+----+---------+------+
    |    |     |           |   bladeenc   |    |         |      |
    |N°  |N° pc|connection | time   time  |num.| wire    |total |
    |case|used | type      | mm.ss  in %  |wire| type    | NIC  |
    +----+-----+-----------+--------------+----+---------+------+
    |  1 |  1  |    -      | mm.ss  100.00|  0 |    -    |   0  |
    |  2 |  4  |hub 10     | mm.ss  xxx.xx|  4 | direct  |   4  |
    |  3 |  4  |switch 100 | mm.ss  xxx.xx|  4 | direct  |   4  |
    |  4 |  4  |P2P        | mm.ss  xxx.xx|  3 | crossed |   6  |
    +----+-----+-----------+--------------+----+---------+------+

these 3 different network topology will be tested to verify the prestational gain in the different situations: the case number one, with only one pc, will be used as milestone, as base to compared on the other results. Of course, the more interesting configuration is the last one, where the cluster will be optimized under topology viewpoint.

Here an ascii-art graphic of the different connections: 

        CASE 2			CASE 3	 	         CASE 4
   +---------------+       +---------------+       +---------------+
   |               |       |               |       |    server     |
   |      hub      |       |    switch     |       |   e   e   e   |
   |    10Mbit/s   |       |   100Mbit/s   |       |   t   t   t   |
   |               |       |               |       |   h   h   h   |
   |               |       |               |       |   0   1   2   |
   +---------------+       +---------------+       +---------------+
     |   |   |   |           |   |   |   |             |   |   |  	
     |   |   |   |           |   |   |   |             |   |   |   	
     |   |   |   |           |   |   |   |             |   |   |	
     |   |   |   |           |   |   |   |             |   |   |  	
    .-. .-. .-. .-.         .-. .-. .-. .-.           .-. .-. .-.	
    |s| |n| |n| |n|         |s| |n| |n| |n|           |n| |n| |n|	
    |e| |o| |o| |o|         |e| |o| |o| |o|           |o| |o| |o|	
    |r| |d| |d| |d|         |r| |d| |d| |d|           |d| |d| |d|	
    |v| |o| |o| |o|         |v| |o| |o| |o|           |o| |o| |o|	
    |e| |2| |3| |4|         |e| |2| |3| |4|           |2| |3| |4|	
    |r| :_: :_: :_:         |r| :_: :_: :_:           :_: :_: :_:	
    :_:                     :_:


CASE 4: DISADVANTAGES

- Called N the numbers of nodes, 2*(N-1) NIC, N-1 on server and one NIC for each node are needed. So, the needed NIC's number grows in linear mode with node number.

- Flexibility is lost because:

- A) Server must be configured how to send network IP packets
- B) Nodes are dedicated overall to give power, because the server 'sees' all the nodes but each single node can sees only the server.
- C) The jobs must be launched from the server (this problem can be bypassed using ssh to control server from remote).
- D) There is a limit to the nodes quantity, given by the number of PCI slots onto the server motherboard. I saw motherboard with 7 PCI slot and one integrated NIC: this means that a cluster with 9 in P2P topology can be built up with only 7 NIC added.


CASE 4: ADVANTAGES
- P2P connection optimizes communication velocity between server and nodes: this would improve the communication on the network: if YES and HOW MUCH is unknown: this is because I am writing this howto :-).

SETTING UP THE SERVER
In my (spasmodic) search of bottleneck to optimize, I find on my street the server, or, in other words, with the hard disk of the server. In fact, the hard disk of the server must support all the I/O load. As we will see below, this load will be heavy: it will be nonsense to optimize the network load without optimizing the I/O load on hard disk: I must avoid the hard disk being a bottleneck for the cluster. The original hard disk (hda) is not so fast: testing it with hdparm -t /dev/hda I get 12.36MB/sec. I added a newer hard disk and install it as hdc. Testing hdc with hdparm -t /dev/hdc I get a better 28.83MB/sec.
We could make the I/O faster putting input files on hdc and forcing output files onto hda: this allow to use both EIDE controller bandwidth. Of course, it would be better to have SCSI hard disks, but, as I said, I am working in economy, using hardware from trash: so, we can't ask more than what we have :-|

HARD DISK OPTIMIZATION

before to start, we have to remember that, with exception of CASE 1, the hard disk of the server will have a heavy I/O load, because ALL the input files will be ready at the same time and ALL the output file will be write at the same time. So, we must avoid that the server's hard disk will be a bottleneck. To do so, the command 'hdparm' can tune the hard disk (man hdparm for details). All in all, the minimum command (for hdc) is: 
# hdparm -c 1 -d 1 /dev/hdc
these option will activate I/O at 32bit and DMA usage.


SOFTWARE USED IN THIS HOWTO

I will use bladeenc, a command line software that allow audio format conversion. I will use bladeenc to convert (with some scripts) several files from WAV to MP3 and to stress the connection between nodes. I downloaded bladeenc from http://bladeenc.mp3.no. I use DEBIAN, so, I used the related .deb package, prepared for Pentium 1 or above.

If you will not use a software that produce a huge network load, you will get no so large benefits form P2P topology: all in all, the server will be ready in case of future needs.

CONFIGURATION FOR HUB OR SWITCH

These configurations are valid for CASE 1, 2, and 3. For CASE 4, I will write in detail how to configure.

/etc/openmosix.map (valid for all nodes) 
        1 192.168.1.1 1
        2 192.168.1.2 1
        3 192.168.1.3 1
        4 192.168.1.4 1
/etc/default/openmosix (valid for all nodes) 
        # This node is a Mosix node.
        OPENMOSIX_NODE=yes
        # Processes are allowed to migrate to other nodes.
        MIGRATE=yes
        # Allow guest processes to arrive.
        BLOCK=no
        # use of MFS (Mosix File System)
        MFS=yes
        #EOF#
/etc/hosts (server) 
        192.168.1.1     server
        127.0.0.1       localhost
/etc/hosts (nodo 2) 
        192.168.1.2     nodo2
        127.0.0.1       localhost
/etc/hosts (nodo 3) 
        192.168.1.3     nodo3
        127.0.0.1       localhost
/etc/hosts (nodo 4) 
        192.168.1.4     nodo4
        127.0.0.1       localhost


FILES FOR TESTS
Let mount hdc1 (the partition with where we will work) on /mnt/hdc1. The partition has inside bladeenc an all the source files: I will work on it through /mfs/0/mnt/hdc1/. That directory has inside 24 audio files is WAV format, they will be converted in MP3 format. To be clear the 24 WAV files are identical: this means that all the conversion jobs will need the same cpu time, so the test will be more homogeneous that it is possible.
To minimize the difference between a test CASE and the other, it is necessary to delete the files audio*.mp3 and audio*.txt at the end of the test.

SCRIPTS FOR TEST

To optimize the prestations, 2 different scripts will be used: one for CASE 1 (only one PC) and one for CASEs 2, 3 and 4.

SCRIPT FOR SERVER ALONE

hang up the clusterin with:

/etc/init.d/openmosix stop

in this way, the server will not move to other nodes his jobs. Now lets write the script.
This script will tell us how much time is needed by only one node to complete the conversion of all files: so, we will have a milestone to confrontate all the other test results.
The script's name is converti.sh and it is the the follow: sequence: 
    #!/bin/sh
    date +%s > /mfs/0/mnt/hdc1/audio.txt
    ./bladeenc -quit -quiet audio01.wav -256 -copy -crc
    ./bladeenc -quit -quiet audio02.wav -256 -copy -crc
    .........................................
    ./bladeenc -quit -quiet audio23.wav -256 -copy -crc
    ./bladeenc -quit -quiet audio24.wav -256 -copy -crc
    date +%s >> /mfs/0/mnt/hdc1/audio.txt

The server works alone, so the conversions are processed one by one to limit the time consumed by Linux's scheduler. In this way the whole scripts is seen as a one process and runs faster.
The script, (thanks to the dommands 'date') create a file named /mfs/0/home/mnt/hdc1/date.txt with 2 number: second minus first will tell, in seconds the duration of the script.

SCRIPT FOR CLUSTER
the script for cluster is named converti-om.sh an inner there are these list of commands: 
    #!/bin/sh
    ./converti01.sh &
    ./converti02.sh &
    ...............
    ./converti23.sh &
    ./converti24.sh &

In this way, the script 'converti-om.sh' sends in background (thanking '&' parameter) other 24 script can migrate one other node, because they are considered 'atomic' by oM.
You must create 24 scripts called 'convertiXX.sh' where XX starts from 01 till 24. The content of the single script is the follow: 
date +%s > audioXX.txt ; bladeenc -quit -quiet audioXX.wav -256 -copy -crc ; date +%s >> audioXX.txt
also here XX must go from '01' to '24'.
Scripts consists of 3 different commands: first command 'date' writes inside the report file called audioXX.txt the time-of-start (in seconds) of the script; command 'bladeenc' is the core of the script and converts the audioXX.wav into audioXX.mp3; the last command 'date' writes inside the report file called audioXX.txt the time-of-end (in seconds) of the script.
Both command 'date' are needed to know when the script starts and finishes: so it easy to calculate the duration, in seconds, of the single scripts.
Comparing the 24 durations, the slower will tell us the duration of the entire conversion jobs.


STARTING WITH TESTS
All the tests must be done onto server (master node).

NOTE: due to external reasons, I cannot use 4 nodes but only 3: that is to say server + nodo02 + nodo03 so I will report about a 3 node cluster, even if you will see that there are 4 nodes.

CASE 1: test on master node with no connection to other nodes (detail)
Run command ./converti.sh, (wait for end) edit audio.txt file, calculate time and archive it on the table.

CASE 2 and 3: HUB AND SWITCH
CASES 2 and 3 are easy because u have co connect the nodes with hub, run the converti-om.sh script, compare the 24 results, achieve in the table the slower. The same job must be done with switch connection. Of course, in CASES 2 and 3 openMosix MUST be active.

CASE 4: P2P TOPOLOGY
Last case is more complex, because you must put inside the server more than one NIC.
Now we enter into the most important part of the howto: in other words, we will see is and how there will be a cluster 'speed up' in function of more number of NIC and consequently a higher network velocity between nodes. 


    	    P2P WITH 4 NODES
                               
	+-----------------------+	
	|                       |
	|          server       |
	|                       |	
	|    e      e      e    |	
	|    t      t      t    |	
	|    h      h      h    |	
	|    0      1      2    |	
	+-----------------------+	
             |      |      |
             |      |      |
             |      |      |
             |      |      |
           .- -.  .- -.  .- -.
           |   |  |   |  |   |
           | N |  | N |  | N |
           | o |  | o |  | o |
           | d |  | d |  | d |
           | o |  | o |  | o |
           | 2 |  | 3 |  | 4 |
           :___:  :___:  :___:
 
                     Node.NIC <-> Node.NIC
                  Server.eth0 <-> nodo2.eth0 
                  Server.eth1 <-> nodo3.eth0  
                  Server.eth2 <-> nodo4.eth0
Now we must turn on all the NICs of the server, tuning them to integradate the network traffic in "intelligent" way to the other nodes.
Contrary to what we could think, it in not necessary to dedicate a IP address to each NIC, but is possible (tanking to kernel 2.4.x and above) to use the SAME ip address for all the NICs of the node.

Here follow the content of /etc/network/interface files of each node.


Nodo A (Server) 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    up route add -host 192.168.1.2 dev eth0
auto eth1
iface eth1 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    up route add -host 192.168.1.3 dev eth1
auto eth2
iface eth2 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    up route add -host 192.168.1.4 dev eth2

Nodo 2 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 192.168.1.2
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255

Nodo 3 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 192.168.1.3
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255

Nodo 4 
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
    address 192.168.1.4
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255


Look with attention the configuration (i.e.) if NIC eth0 of the server: 
auto eth0
iface eth0 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    up route add -host 192.168.1.2 dev eth0
First six rows are clear, the last row is the "magic" instruction: in fact it menas: "all and the only communication between the current IP (192.168.1.1) that are to IP 192.168.1.2 must be sent to NIC called eth0". In this way, there are no collisions because there are only peer-to-peer connections: shortly P2P.

RESULTS ANALYSIS

The WAV files are 89782940 byte each, the generate MP3 files are 16287870 byte each.

Doing some counts, there are about 2426MB that must go 'up an down' on the network. As you can see, I filled the table with the test's results: there is als a ascii-art representation to make them easy to be seen:

    +----+-----+-----------+--------------+----+---------+------+
    |    |     |           |   bladeenc   |    |         |      |
    |case|N# pc|connection | time   time  |num.| cable   | N# of|
    | N# |used |  type     | mm.ss  in %  |wire| tipe    |  NIC |
    +----+-----+-----------+--------------+----+---------+------+
    |  1 |  1  |    -      |107.39  100.00|  0 |    -    |   0  |
    |  2 |  4  |hub 10     | 41.12   38.27|  4 | direct  |   4  |
    |  3 |  4  |switch 100 | 39.28   36.66|  4 | direct  |   4  |
    |  4 |  4  |P2P        | 37.40   34.98|  3 | crossed |   6  |
    +----+-----+-----------+--------------+----+---------+------+

To be more complete for CASEs 2, 3 e 4, the slower and faster jobs are shown here.

TYPE         SLOW    FAST     DIFF   DIFF%
hub10MB/s   41m12s  39m01s   2m11s   5.3%
switch      39m28s  38m58s   0m31s   1.3%
P2P         37m40s  36m44s   0m56s   2.5% 


num  type  CASE         20%       40%       60%       80%       100%
pc   conn.         10%   |   30%   |   50%   |   70%   |   90%   |
                    v    v    v    v    v    v    v    v    v    v
 1     -     1  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 100.00%
 2  hub10    2  OOOOOOOOOOOOOOOOOOO.    |    |    |    |    |    |  38.27%
 3  sw100    3  OOOOOOOOOOOOOOOOOOo|    |    |    |    |    |    |  36.66%
 4  P2P      4  OOOOOOOOOOOOOOOOOo |    |    |    |    |    |    |  34.98%
                -------------------------------------------------- 
                % time in function of the single PC.


Why in CASEs 2, 3 and 4 the time are quite similar? It is not what we expected for.

VELOCITY TEST BETWEEN NODES

Let us see what are the communication velocity between the nodes, for CASEs 2, 3 and 4: to do it, I will copy a file of 320M from server to nodo02 calculating the time needed for each type of connection. Make a test file of 32M:

dd if=/proc/kcore of=pippo bs=1k cout=32768

Let use it to create a file 10 times bigger

cat pippo pippo pippo pippo pippo pippo pippo pippo pippo pippo > prova

The resulting file is long 334455320 Byte: exactly 320M.

Copy prova file from server to nodo02:

time cp prova /mfs/2/root

This command must be repeated for hub, switch and P2P connection (remember to modify the file /etc/network/interfaces on the server accordingly for the connection type). Here the results. 

CONNECTION        TIME(sec)   PERCENTAGE        MB/s
hub 10Mbs         337.4       100.0%            0.95
switch 10/100Mbs  453.3       134.3%            0.70
P2P                71.5        21.2%            4.47


Switch 10/100Mb/s gave a worse result: in this case switch usage is not advantage.

As you see P2P connection is the best under velocity viewpoint. But why the cluster didn't run faster?
Most probably, for this cluster the network velocity IS NOT a bottleneck.
It seams obvious that bottleneck is elsewhere: if I do again test 2 and 3, using iptraf to monitor the network traffic, I can see (in CASEs 2 and 3) that network I/O is about 750-830KB/s. That value is easily handed by hub of switch.

So, where bottleneck is? The problem comes from nodes CPU that cannot elaborate a quantity of data great enough to saturate a hub or switch's bandwidth in CASEs 2 and 3.

I should be used more nodes and/or more powerful nodes, like P3 or P4, but I have not that hardware.... How to proceed? I can try to make lighter the conversion script as follow: 
date +%s > audioXX.txt ; bladeenc -quit -quiet audioXX.wav -256 -mono ; date +%s >> audioXX.txt
So, the conversion will be mono and not more stereo, using half CPU time.
Here new results (I done again ALL the tests):



    TYPE          SLOWER  FASTER   DIFF   DIFF%
    hub10MB/s     28m29s  21m10s   7m18s  25.7%
    switch        25m56s  12m04s  13m52s  53.5%
    P2P           19m42s  17m38s   2m04s  10.5%


It is interesting to see that using switch, there are a BIG difference between faster and slower job. On 24 jobs, there was 3 job faster than 14 minutes.

Now we can give a value to that famous unknown labels X,Y, Z, T e W.

The initial sentence was: "A 4 node cluster with CPU at ZMhz connected with Y topology is equivalent to a single PC running at Whz when do the job T".

now it becomes:
"A 3 node cluster with CPU Pentium 2 a 300Mhz connected Y topology is equivalent to a single PC running at WMhz when does a 24 audio conversion jobs".

There are only to determinate the values for Y (topology) and W (Mhz).
That values are (after all test rerun) shown in this ascii-art table: 
   conn. CASE          20%       40%       60%       80%       100%
   type           10%   |   30%   |   50%   |   70%   |   90%   |
                   v    v    v    v    v    v    v    v    v    v
     -      1  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 100.00% 53m53s
   hub10    2  OOOOOOOOOOOOOOOOOOOOOOOOOOo  |    |    |    |    |  52.86% 28m29s
   sw100    3  OOOOOOOOOOOOOOOOOOOOOOOO|    |    |    |    |    |  48.13% 25m56s
   P2P      4  OOOOOOOOOOOOOOOOOOo|    |    |    |    |    |    |  36.56% 19m42s
               -------------------------------------------------- 
               Percentage of time in function of a single PC.
As u can see in CASE P2P the time is 36.56%, near the theoretical maximum of 33.33% (33.33% is theoretical because it is never reachable)


Labels Y e W get now these values:


   PC      Topology    Equivalent power      Max. theoretic	difference
   num     (Y)        (W)                    power
   1       -           300Mhz                -                   -
   3       hub         567Mhz                900Mhz         -36.94%
   3       switch      623Mhz                900Mhz         -30.74%
   3       P2P         820Mhz                900Mhz         - 8.88%
Putting together 3 CPU at 300Mhz, we could hope to get, at maximum a equivalent power of a virtual CPU running at 900Mhz in this case, we have the results of 820, less than 9% under the theoretical maximum. We can see that there is eqvident and convenient increment of prestations that came only from different topology: the cluster "grows" well, and this justify and compensate the disadvantages of P2P topology.

     conn. CASE         20%       40%       60%       80%       100%
     type          10%   |   30%   |   50%   |   70%   |   90%   |
                    v    v    v    v    v    v    v    v    v    v
    hub10    2  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 100.00% 28m29s
    sw100    3  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOo   |  91.04% 25m56s
    P2P      4  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOo|    |    |    |  69.16% 19m42s
                -------------------------------------------------- 
                Percentage of time in function of hub10Mb/s topology

Let analyze the topology setting hub topology as 100%.

Shortly, the P2P gains il 20% on switch and 30% on hub.

Because in a real situation it is more easy to use switch, we can do this relation:

     conn.  CASE         20%       40%       60%       80%       100%
     type          10%   |   30%   |   50%   |   70%   |   90%   |
                    v    v    v    v    v    v    v    v    v    v
    sw100    3  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 100.00% 25m56s
    P2P      4  OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO |    |    |  75.96% 19m42s
                -------------------------------------------------- 
                Percentage of time in function of switch10/100Mb/s topology

In this case, P2P gains 24% on switch.


FURTER DEVELOPMENTS: PRESTATION FORECAST

It is interesting to see that using this table: 

   PC      Topology    Equivalent power      Max. theoretic	difference
   num     (Y)        (W)                    power
   1       -           300Mhz                -                   -
   3       hub         567Mhz                900Mhz         -36.94%
   3       switch      623Mhz                900Mhz         -30.74%
   3       P2P         820Mhz                900Mhz         - 8.88%
it is possible to forecast the maximum power that came from adding furter nodes: 3 nodes->820Mhz, 4 nodes->1095Mhz. Because P2P eliminates the bandwidth bottleneck, the power of 4 nodes must be read as "not less than" 1095Mhz. I would had pleasure to had enough PCs to test and write "prestational curve" for pc_num vs Equivalent _power.... Perhaps, I will do next time :-)

FURTER DEVELOPMENTS: P2P CUSTER BIGGER THAN 9 NODES

Because the server must "see" all the other nodes on a different NIC, I previously said that the NIC's number is equivalent to numbers of nodes, but this is not totally correct.

In fact, exists NICs with 2 network points: shortly, they doubled the chipset on the same PCI board. I did not used them thill now, but if they function it will be possible to have 16-nodes cluster (7 slot PCI * 2 NIC + 1 NIC on board + server node).

Alternatively, there is another possibility: to create 2 different P2P cluster linked with a NIC running at 1Gb/s or 2-3 NIC configured with channel bonding. As usual I have not enough hardware to do this: perhaps, in future.

CONCLUSIONS

I shown that a cluster,

- IF with an appropriate configuration,
- AND when it processes jobs needing huge network I/O,

- CAN have a good 'speed up' with a easy network topology modification ad with some inexpensive NICs.

In other words, a P2P cluster shows its power where there are masses of data to elaborate and when the network I/O is a bottleneck to eliminate or to reduce.

NICE TO HAVE

It would be good to have more PCs and/or more powerful PCs: 10 o 12 Pentium III at 1Ghz with 256Mram (now, feb-2004, that hardware can be considered as low/medium level) to do more exhaustive tests... Well, you can do those tests: or, if you provide me that PCs, I will do for you :-)


CREDITS

This howto came from a my own idea.
Thanks to:
- an openlabs member (I do not remember name) for
up route add -host 192.168.1.X dev ethY ,

But, overall, I thank myself for obstinacy shown to do this work (delayed for too much time due to absence of hardware) and because I worked hard to do this: well done, Roby!

(NOTE FOR NON-ITALIAN SPEAKERS: "I worked hard" does not give the right idea of difficulties I found: it is a rude/foyer and not correct translation of italian sentence "mi sono fatto un mazzo cosi'", but it is just a slang term, an I do not know the English version of it: anyway, in italian it sounds good :-))


DATA ABOUT ME

Here my mail adresses:

roberto.premoli(at)tiscali.it
or
r00(at)excite.it