View Full Version : OpenMosix Minipaper 0.2 per il LinuxDay 2002: v0.2
rejected
24-10-2002, 17:57
Salve a tutti.
Scusate il disturbo.
In vista del prossimo LinuxDay (23 Novembre 2002), sto scrivendo un minipaper su OpenMosix che verterà su:
- OpenMosix: perchè non tutti i programmi funionano
- Programmazione su OpenMosix: come rendere migrabile i programmi
- Miei test in C,C++,Java su OpenMosix: prove e risultati.
- Thread supportati da OpenMosix
- Tipologie di thread in Linux.
- Tipologie di thread nelle JVM sotto Linux
- ...
Lo trovate su: http://filibusta.crema.unimi.it/mos...x_minipaper.htm)
Qualunque forma di collaborazione è sempre ben accetta.
Grazie.
<rejected>
PS: un saluto a AlexMaz, ilsensine, Taddeus e Flisi71: è un po' che non ci sente... :)
ciao :)
è un po' che non uso Mosix... volevo appunto passare a OpenMosix e fare un po' di test... appena risistemo il mio pc principale faccio tutto e scarico il tuo minipaper.
ciao
Ciao amici, come state?
E' davvero un pò di tempo che non ci si risente per bene, e qualcuno dovrebbe svegliare anche quello "sfaticato" di taddeus!!!
:)
Seguo sempre l'evoluzione del tuo tutorial (e me lo stampo di conseguenza), ma non ti posso aiutare, perchè sono MOLTO più ignorante di te, e i tuoi scritti non mi servono come spunto per riflessioni, ma come testo di studio!
Ho provato ad utilizzare anche la mini-distribuzione Plump-OS, ma non mi si aggancia al resto del cluster, pur utilizzando il kernel 2.4.19 e openmosix4 anche nei nodi "interi". Te l'hai provato?
Inoltre: il server dhcp lo volevo implementare in un nodo openmosix, ma non mi funziona (mi ricordo che anche sul cluster Mosix non mi funzionava). Tieni conto che finita l'installazione di linux su di un nodo, ho configurato e attivato il server dhcp, verificato il suo funzionamento, ma una volta patchato il kernel con OpenMosix il server dhcp non mi funziona più e devo ricorrere ad una macchina esterna (a dire il vero questo non è un problema grave, perchè tanto poi i nodi Plump-OS non mi si attaccano comunque, quindi in definitiva non mi è utile il server dhcp). Avevo letto nelle tue note per implementare macchine con ClumpOS di usare "...una macchina anche poco potente, con il server dhcp (dhcpd)...", e mi è sorto il dubbio che non hai specificato l'opzione più immediata, cioè di implementarlo direttamente in un nodo del cluster, probabilmente perchè c'è qualche problema. E' forse così?
Ciao
Federico
rejected
08-11-2002, 20:29
Ciao Flisi. Salve a tutti gli altri.
A quanto pare il minipaper ha attirato l'attenzione del Cineca.
Mi hanno chiesto di presentarlo (insieme agli altri miei amici) all'Openmosix Workshop del prossimo 28 Novembre 2002 in quel di Bologna. Sito: http://www.cineca.it/events/openmosix.
Se otterrò le dovute autorizzazioni (per parlare a nome della mia Uni) e avrò conferma che qualcuno dle mio gruppo viene con me, probabilmente accetterò l'invito.
Quanto allo sviluppo del minipaper ho la gran fortuna di poter contare sull'aiuto dei miei amici dell'Uni e, rulli di tamburi..., del mio professore di Sistemi Operativi.
Quanto all'aiuto nello sviluppo, non è necessario che tu conosca l'argomento e/o tu sia strettamente competente in materia (non è che sia un genio neppure io, anzi...). Per intenderci, un semplica verifica grammaticale è già un _notevole contributo_.
Intanto ti ringrazio x l'interesse dimostrato...
Byez...
<rejected>
rejected
08-11-2002, 21:06
Ho provato ClumpOS a casa tempo fa.
Alleìepoca (si parla di più di 6 mesi fa), ho preso una macchina con Linux già installato (Mandrake,non mi rcirod che versione) e dopo aver ricompilato il kernel col supporto per Mosix, ho attivato rete e dhcp server (configurandolo perchè assegnasse ai nodi indirizzi ip appartenenti allo stesos segmento di rete di questa macchina).
Poi ho preso un'altra macchina con Windows e ho fatto il boot con il cd bootable di ClumpOS (che attiva anche la rete ed il client dhcp). ClumpOS ha ricevuto correttamente l'IP (stesso segmento di rete) e subito ogni nodo si è accorto dell'altro.
Ho poi lanciato il mio solito script di test (un loop infinito tipo quello del minipaper) che ha poratto Mosix a reagire.
L'esperiemtno, condotto a casa, ha avuto una pubblica dimostrazione il giorno seguente in Uni davanti ad alcuni miei amici (1 macchina Linux installata e 3 client ClumpOS diskless). Anche in questo caso non si sono verificati problemi ed il test ha avuto successo.
ClumpOS è stato fatto con l'intenzione di mettere in piedi al volo una macchina Mosix via dhcp. Installare un cluster con macchine non-diskless è leggermente più difficile. Il problema non è tanto l'assegnazione degli IP quanto la propagazione della mappa dei nodi a ciascun nodo. ClumpOS automatizza questo passaggio.
Probabilmente nelle future versionid OpenMosix il concetto di mappa e/o distruzioni di mappa dei nodi verrà meno (automatizzata).
Conosco PlumpOS (ClumpOS è per Mosix, PlumpOS è per OpenMosix),ma non l'ho ancora provato (ho scaricato la ISO ma non l'ho testata x' a casa ho dei problemi a ricompilare il kernel+patch_O.M.sotto Mandrake 9.0).
In ogni caso, se posso esserti d'aiuto, chiedi pure...
<rejected>
Ciao rejected e innanzitutto grazie per la tua risposta!
Anch'io ho utilizzato con profitto ClumpOS (il mio cluster Mosix che avevo implementato aveva un solo nodo "intero" e tutti gli altri erano nodi ClumpOS che facevo partire uno alla voltas perchè avevo masterizzato 1 solo cd!; il problema anche allora è che dovevo tenere accesa una macchina - un vecchio P200 con mandrake72 - con il servizio dhcpd, visto che il nodo intero non ne voleva sapere di avviarlo.
Nota: prima di patchare il kernel con mosix il servizio dhcpd funzionava.
Poi sono passato a OpenMosix, utilizzando per semplicità RH7.x con bootloader Grub, così che l'installazione diventa elementare.
Ho poi cercato di utilizzare PlumpOS, visto che è molto interessante poter disporre di nodi, anche temporaneamente, da aggiungere al cluster senza modificare alcunchè.
Qui arriva il problema che ho attualmente: il nodo PlumpOS, benchè parta correttamente, riconosca la NIC, prenda l'indirizzo IP
dal pool corretto che è inserito anche in /etc/mosix.map, NON SI UNISCE al nodo rh7.3+OpenMosix4.
leggendo le scarne note su PlumoOS sembra che richieda il kernel 2.4.19OpenMosix4; bene, allora aggiorno il kernel al nodo "intero", installo lo specifico OpenMosix r4 per quel kernel, la macchina riparte bene, ma il nodo PlumpOS continua a non volersi unire al pool! Problemi di rete non ve ne sono (visto che con VNC posso accedere dal nodo "intero" al nodo PlumpOS), ma comunque non posso unire il nodo PlumpOS con quello "intero".
Hai nessuna idea o tentativo che io dovrei fare?
Ciao
Federico
P.S. Sono capitato solo per caso al lavoro, ma mi piacerebbe poter partecipare al workshop del 28 novembre prossimo. Magari lunedì cercherò di sondare la disponibilità del dirigente (la vedo ahimè dura)
rejected
09-11-2002, 19:54
Sul problema col DHCPD:
- Hai abilitato il supporto arp/dhcp/bootp/... nella configurazione della rete?
- Hai provato a reinstallare i pacchetti del dhcp(d) dopo la ricompilazione del kernel? E' un comportamneto "alla Windows",ma a volte funziona... :)
- Le due macchine si vedono e/o sono sullo stesso segmento di rete? Hai un qualche stupido firewall extra abilitato (ipchains,iptables,firewall di redhat,...) che permette il traffico "normale" (http,...) ma blocca quello di OpenMosix? A me è capitato di disabilitare ipchains e iptables ma un firewall extra di RedHat permaneva e impediva comunicazione _solo_ a OpenMosix.
- ...
Fammi sapere se riesci a sistemare questo problema.
Per me il problema sta nel fatto che PlumpOS è un progetto giovane e,magari , è un problema di quella specifica release.
Anche ClumpOS alle origini aveva dei problemi in questo senso...
Quanto all'evento di Bologna.
Probabilmente parteciperò. Sicuramente a nome del LUG di Crema e, se avrò l'autorizzazione, anche a nome dell'Uni.
Byez... :)
<rejected>
Grazie della celere risposta!
Ora proverò con i tuoi consigli.
Ciao
Federico
P.S. Sto provando a scaricare mandrake-CLIC, te l'hai provata?
rejected
11-11-2002, 14:46
Volevo scaricarla,ma non ho avuto il tempo.
Ultimamente scuola (con il minipaper),lavoro e ragazza mi hanno assorbito totalmente... :)
Quando avrò un po' di tempo,magari la proverò.
Sembra una bella idea,cmq...
Fammi sapere se hai risolto o meno i problemi con PlumpOS...
Byez.
<rejected>
Ciao, ho visto l'ultima(?) evoluzione del tuo tutorial, complimenti!!!
Mi sono registrato anch'io per il Workshop del Cineca, e spero proprio di esserci insieme al nostro presidente del LUG.
(Speriamo di non avere problemi di lavoro!)
Ho provato il Mandrake CLIC; l'installazione chiaramente non presenta problemi, poi viene il bello di iniziare ad utilizzarlo. E dunque giù a leggere pagine e pagine di manuali.......e il tempo è tiranno.
Per quanto riguarda OpenMosix, ho deciso di accantonare momentaneamente PlumpOS e di utilizzare solo nodi "interi", ottenendo così anche il vantaggio di poter operare da qualunque nodo.
Terrò comunque sempre sott'occhio l'evoluzione del PlumpOS, perchè comunque in determinati ambiti può essere utile poter disporre temporaneamente di potenza di calcolo aggiuntiva!!!
Ti saluto.
Ciao
Federico
....scusate, post doppio!!
Ciao
Federico
rejected
13-11-2002, 16:18
Prima di tutto ho ottenuto l'autorizzazione ufficiale a partecipare all'evento come Polo di Crema (e ciò è cosa molto gradita! :) ).
A quanto pare, a causa della concomitanza con un altro evento in Uni (con priorità più alta), probabilmente il LinuxDay a Crema non si potrà fare. Tristezza... :(
Quanto al minipaper,sto lavorandoci ancora e intendo ultimarlo entro il 23 (che il LinuxDay si tenga o meno).
Di importante mancano ancora i Pthread su OpenMosix (magari con qualche esempio in C++). Poi vedrò,tempo permettendo, di rivederlo dall'inizio e aggiungere qualcos'altro... :)
Dopo il Workshop vedrò di testare Clic,PlumpOS,... e poi ti dirò.
Se anzi,hai qualche cosa di interessante da segnalarmi per il minipaper, sono ben felice di includerlo!
La cosa che ora mi preoccupa (molto) è sostanzialmente una: come raggiungere il Cineca??? :)
Byez.
<rejected>
Allora se ci sei anche te, cercherò in tutti i modi di venire (sto già inventando la scusa)!!!!
Riguardo a come raggiungere il cineca, se ci vai in auto non credo tu possa sbagliare, perchè mi ricordo che l'edificio del CINECA si vede dall'autostrada, per cui uscendo a Casalecchio basterà anche andare ad intuito. Se ci vieni in treno (come faremo io e Graziano, il nostro presidente del LUG) invece credo che senza immattimenti convenga prendere subito il taxi.
P.S. Quando è previsto il tuo intervento (così ti vedo di persona)?
Ciao
Federico
rejected
14-11-2002, 11:47
Sto organizzandomi con i miei amici del LUG/Uni per venire in auto. Vorrei essere al Cineca per le 9, prima dell'inizio, così forse riesco a parlare per qualche minuto con gli organizzatori.
Ciò significa che per essere sicuri dovrei partire da casa mia per le 6 o anche prima.
Stando a quanto riportato sul sito del Workshop (http://www.cineca.it/events/openmosix/) dovrei parlare per secondo, quindi dopo le 14:30 o giù di lì.
Mi è stata richiesta un'esposizione sui 15-20 minuti.
In ogni caso, uno di questi giorni dovrei ricevere tutte le info in maniera dettagliata. Quando so qualcosa di più, lo posto subito...
Incontrarci non è un problema. Qualche idea? Tieni conto che io non conosco per niente il Cineca. :)
Ho già capito che questa settimana non andrò a letto prima delle 3:00/3:30 tutte le sere. :)
Devo finire assolutamente (e bene) il minipaper e fare 2 esami (domani quello del corso FSE su Linux Avanzato... Speriamo bene... :) ).
<rejected>
Allora super in bocca al lupo!!!!!!
Comunque a te conviene andarci con l'auto, visto che sono circa 200 KM di pianura a 3 corsie, mentre a me non conviene dovendo passare l'appennino in un giorno feriale.
Io spero di poterci incontrare, ma neanche io conosco il Cineca da dentro, ti dico solo che dall'autostrada si vede il palazzo con la scritta, nei pressi dell'uscita dell'A1 di Casalecchio di Reno (però non sono sicuro se io la vedo prima dell'uscita o subito dopo, se io la vedo prima dell'uscita allora te potresti non vederla perchè provieni da nord)
P.S. Io sono ancora qui fino a domani mattina compreso. Poi non ti potrò più rispondere fino al lunedì 25, quando rientro al lavoro.
P.S. Tieni presente che torno in Italia sabato 23, appositamente per partecipare al LinuxDay qui di Arezzo (infatti sarei potuto rientrare anche il lunedì mattina presto)
:)
Ciao
Federico
rejected
14-11-2002, 14:31
Povera bestiola: a furia di fare questo tipo di augurio deve avere addosso una iella di quelle mastodontiche. :)
Speriamo di incontrarci, allora...
Byez.
<rejected>
Guarda, oggi a pranzo ne ho parlato al responsabile del nostro CED che era in giornata buona, e mi ha concesso di venirci di sicuro!!!
Incredibile: martedì gli ho chiesto la settimana prossima di ferie, oggi gli ho chiesto il giovedì successivo, e in tutti i casi NON ha battuto ciglio.
Magari ne approfitto anche per chiedere un adeguamento del compenso!!
:)
Comunque a parte gli scherzi io lunedì 25 sarò regolarmente qui e perciò abbiamo tutto il tempo per aggiornarsi e magari stabilire un sistema per incontrarci.
Ciao
Federico
rejected
14-11-2002, 16:41
Ok. Ci metteremo d'accordo quando tronerai...
Buone ferie/vacanze/... (vedi tu come chimarle).
Byez.
<rejected>
Grazie, vado a prendermi un pò di gelo.......
:)
Ciao
Federico
rejected
19-11-2002, 01:23
Ciao Federico.
Siamo alla versione 0.6 dle minipaper. Tra qualche giorno rilascerò la 1.0 e via, pronti per l'Openmosix Workshop.
Mi piacerebbe sapere il tuo parere su questa release.
Che ne pensi?
Scusa il disturbo & grazie per l'interessamento.
Byez.
<rejected>
Io l'ho letto, mi sembra buono... l'unico punto che mi convince poco, ma non per colpa tua, è quello sull'implementazione dei thread... per definizione, credo, i thread di uno stesso processo devono condividere lo stesso spazio di indirizzamento (per "operare" sugli stessi dati) quindi anche i thread su altri OS avrebbero gli stessi problemi di migrazione che su linux. Questa almeno è una mia impressione, da verificare :)
ciao
rejected
19-11-2002, 17:12
Ciao Alexmaz. Grazie per il suggerimento.
In effetti ciò che dici è giusto. I thread per definizione (quindi su qualunque SO "standard" che supporti i thread) condividono tanto lo spazio di indirizzamento quanto altre risorse (process descriptor incluso).
Ma, se i thread fossero...
- indipendenti "logicamente" fra loro (ognuno fa il suo lavoro senza curarsi degli altri).
- magari la libreria dei thread fosse in user-space (le librerie in kernel-space sono troppo legate al sistema ospitante)
...allora Mosix, IMHO, potrebbe sganciarli e riattaccarli sui vari nodi.
In ogni modo la futura cluster-shared-memory dovrebbe risolvere il problema a monte.
Intanto grazie per la segnalazione: ne terrò conto.
Grazie.
<JP>
Si infatti parlavo di thread a livello kernel... per quelli in user-space in effetti non dovrebbero esserci problemi (sempre a seconda dell'implementazione) ma secondo me non sono una gran soluzione (non in questo caso a livello di test, ma in generale) in quanto l'OS in se (il kernel) non è a conoscenza dell'esistenza di + thread all'interno di un processo e questo ha le sue noiose conseguenze...
ciao :)
rejected
19-11-2002, 22:35
Ragionamento corretto il tuo, Alexmaz.
Infatti i thread totalmente in user-space sono invisibili al kernel e ci vuole qualcos'altro che li gestisca (altre librerie => nuove sovrastrutture => probabile decremento delle prestazioni).
Se però pensi che esiste più di una versione del kernel Linux in user-space ciò signifca che qualcuno probabilmente ha già creato queste sovrastrutture... :)
Byez.
<rejected>
Ho mandato il form per il convegno, se riesco vengo... :)
rejected
20-11-2002, 22:47
Allora magari ci si vede... :)
Fammi sapere che magari ci organizziamo per trovarci al Cineca...
<rejected>
Io cerco di venire... e se vengo cerco di venire in macchina che mi è più comodo...
Ho installato openMosix su 3 pc a casa (che fatica usare + distribuzioni, bisogna ricordarsi troppo roba :D ) ...
figata:
uno dei nodi è un Pentium Pro 200... mi sono collegato in ssh e ho notato che rispondeva meglio... guardo e... sshd è migrato sull'Athlon XP :p
fantastico :D
è velocissimo nel migrare i processi!!! ho lanciato il mio complesso test stressa cpu
main(){
for( ;; );
}
:D
e dal Pentium Pro e schizzato subito sull'Athlon... :p
rejected
22-11-2002, 14:50
Il programmino migra perchè
- Occupa la CPU al 100%
- Occupa pochissima Ram, ma le risorse (memoria esclusa) coinvolte sono enormi
- Openmosix vede che il programma non fa altro che consumare tempo di CPU (senza operare su variabili condivise,...) e quindi il relativo processo è migrabile.
Nota che le varie instanze dle programmino sono processi (creati dalla shell tramite fork()/exec()) e non thread e, di fatto, sono tranquillamente migrabili.
Prova il mio programmino che usa i PThread (ptDiv):
http://filibusta.crema.unimi.it/mosix/openmosix_minipaper.htm
(sezione: PThread e OpenMosix (WIP)"): vedrai che non migra... (a me non migra).
Poi leggi sotto (a quella sezione), perchè non va... :)
>> Anzi, se lo provi e mi dici se è successo qualcosa, mi fai un grosso piacere. (In questo momento sto ricostruendo il cluster e non posso utilizzarlo!) <<
Grazie...
<rejected>
Non migra...
secondo me questo semplice esempio rispecchia un problema nell'implementazione di thread e processi di linux, che era gia venuto fuori in una discussione qui qualche tempo fa...
capisco il problema di migrare un singolo thread di un processo, ma se io volessi migrare tutto il processo non si sarebbero problemi... ma con linux non posso! Qual'è il pid del processo? se dai un ps aux vedi che vengono elencati tutti i thread creati con pid diversi e questo è semanticamente sbagliato. O meglio, in linux non esistono entità processi o thread, ma diciamo dei task che possono condividere o meno lo spazio di indirizzamento e altre risorse. Questo secondo me è un limite, soprattutto per applicazioni di questo tipo.
Infatti...
The Linux POSIX thread implementation is using individual processes for each thread. These are not completely separated processes but instead since they have to shared things like virtual memory, file descriptors and the like.
However, the kernel does not really know the difference between threads and processes. Therefore it does not handle the delivery signals correctly. There is no single process ID (each thread has its own, which is another difference from the POSIX standard) and the kernel is delivering the signal to that thread.
rejected
22-11-2002, 21:12
Tratto da:
http://pauillac.inria.fr/~xleroy/linuxthreads/faq.html#K
"K. Internals of LinuxThreads
K.1: What is the implementation model for LinuxThreads?
LinuxThreads follows the so-called "one-to-one" model: each thread is
actually a separate process in the kernel. The kernel scheduler takes care of
scheduling the threads, just like it schedules regular processes. The threads
are created with the Linux clone() system call, which is a generalization of
fork() allowing the new process to share the memory space, file descriptors,
and signal handlers of the parent.
Advantages of the "one-to-one" model include:
* minimal overhead on CPU-intensive multiprocessing (with about one
thread per processor);
* minimal overhead on I/O operations;
* a simple and robust implementation (the kernel scheduler does most of the
hard work for us).
The main disadvantage is more expensive context switches on mutex and
condition operations, which must go through the kernel. This is mitigated by
the fact that context switches in the Linux kernel are pretty efficient."
Devo correggere un po' di cose...
<rejected>
Il problema è che proprio il concetto di processo non esiste o quasi... anche Windows 2000 fa lo scheduling dei thread e non dei processi, ma il pid è assegnato per processo, non per thread...
rejected
23-11-2002, 01:02
Hai ragione, ma ci sono alcune differenze...
Windows e Linux (stando a quello che emerge leggendo il nuovo Tanenbaum) sono due entià distinte anche se entrambi muovono thread e non processi (come fa invece lo UNIX standard).
In Windows ci sono 4 tipi diversi di contesti di esecuzione:
- Job
- Process
- Thread
- Fiber
E come giustamente hai detto tu, il thread è il vero "context of execution" e il process è il contenitore (e ha il PID). Il kernel schedula quindi i thread.
In Linux abbiamo soltanto processi e thread. Anche in questo caso lo scheduler muove solamente la parte in kernel-space e quindi solo i "thread kernel, e per questo, lo scheduling è sempre basato sui thread e mai sui processi" (Tanenbaum).
D'accordo con te che non ci sia una differenza enorme fra thread e process in Linux, ma ognuno di essi ha un suo PID univoco (il processo padre deve pur sapere come chiamare i suoi figli).
Se lanci ptDiv vedrai che ogni thread ha il suo PID (guarda top e/o ps aux).
(http://www.oreilly.com/catalog/linuxkernel/chapter/ch10.html)
Ovvio che killando un thread, provochi la morte di altri thread e, probabilmente, anche del process parent.
Che ne pensi?
<rejected>
Si si, ma il problema sta proprio nel fatto che non c'è un pid per il processo, ma solo i pid dei thread... se io mi volessi riferire al processo, che pid prendo?
In sostanza il processo per il kernel non esiste, esistono solo dei thread con lo stesso spazio di indirizzamento e stessi descrittori dei file... è la stessa cosa, però...
rejected
23-11-2002, 01:23
Leggendo la FAQ ufficiali dei LinuxThreads (i thread in kernel-space interni a Linux),
si legge che "The kernel scheduler takes care of scheduling the threads, just like it schedules regular processes. ".
La citazione è tratta dalla sezione "K. Internals of LinuxThreads".
Ora, siccome Tanenbaum parla dei thread del kernel 2.2 e queste FAQ sono quelle ufficiali scritte dagli autori dei thread di Linux serie 2.4, direi che do la palma del vincitore agli autori della FAQ.
Quindi posso dire che Linux, muove thread e processi e non solo thread come Windows2000/XP...
O sbaglio?
PS: ora voglio vedere cosa cambierà con la serie 2.6... :)
<rejected>
rejected
23-11-2002, 01:29
Prendi un processo monothread.
Ogni processo di questo tipo ha un (solo) main-thread in kernel-space. Il PID è quindi assegnato al main-thread e quindi,di riflesso, al processo.
Anche nel caso di processi a thraed multipli esiste cmq un main-thread per caiscuno (quello col PID più basso, perchè è il primo ad originarsi). Di fatto esiste quindi un PID per il mainthread-processo e n PID per i thread che si dipartono da esso (che sono anch'essi in kernl-space).
Che dici?
<rejected>
No secondo me lo scheduler muove solo i thread, non ha possibilità di muobere i processi...
si c'è sicuramente un thread "principale" o di controllo... cmq tutti i thread in linux sono visti a livello kernel, questo è sicuro
Sono appena rientrato e passo qui di sfuggita proprio per leggere gli ultimi sviluppi, e chi ci trovo? il nostro amico Alexmaz!!!
Bene, benissimo.
Ora devo finire di sistemare alcune cose ma lunedì mi leggo tutto e provo a postare qualcosa di utile!!!!
Ciao!!!
P.S. Grazie della tua premura di tenermi informato!!!
Federico
rejected
23-11-2002, 13:30
Ciao Flisi. Passate bene le vacanze?
---- O ----
Alexmaz, ora spiego bene cosa intendevo col post intitolato "PID".
Il kernel muove solo parti in kernel-space quindi muove solo i thread.
Siccome i processi hanno una parte in kernel space (il main-thread) ed una parte in user-space sembra che anche i processi siano schedulati mentre nella realtà sono schedulati _solo_> i suoi thread in kernel-space(il main e quelli che si dipartono da esso, come i PThread).
Di fatto la definizione di Tanenbaum è la più corretta (Linux schedula solo i thread).
Ma sebbene la cosa risulti fuorviante, anche la definizione trovata sulle FAQ dei LinuxThreads non è errata "logicamente": di fatto il processo è/ha un thread a sua volta e quindi potremmo dire che viene schedulato anche lui (perchè lo è il suo main-thread!).
E' solo un equivoco a livello lessicale/logico.
In ogni caso (ribadisco): Linux muove solo thread, non processi!
Va bene, come spiegazione?
<rejected>
rejected
23-11-2002, 13:37
Dimenticavo :ho preparato le slide definitive per il Workshop.
Potreste dargli un occhiata e dirmi cosa non va?
(Per Alexmaz: non ho la tua mail. Puoi mandarmela con un messaggio privato?)
Sono una ventina di slide e si leggono in 15 min scarsi. Il formato è PowerPoint (mi è stato richiesto esplicitamente questo formato...).
Devo presentare il tutto entro lunedì (penso mattina) e quindi i tempi stringono... :)
Grazie infinite.
<rejected>
rejected
23-11-2002, 22:17
Grazie mille, Alexmaz e Flisi x l'aiuto che mi state dando...
A buon rendere...
<rejected>
Ciao, vedo che ADDIRITTURA ci hai citato nei ringraziamenti!!!!!
Grazie mille.
:)
E ora passiamo al pratico: come facciamo ad incontrarci al Cineca, magari prima che inizi il workshop o durante una pausa?
Qualche idea?
Ciao
Federico
rejected
25-11-2002, 11:17
Se non ci sono problemi, dovrei essere al Cineca per le 9.00.
Potremmo sentirci via cell per trovarci.
Che ne dite?
Fatemi sapere...
<rejected>
PS: sono in totale paranoia... A 3 giorni dal Workshop siamo passati da un comodo "la conferenza è in italiano", ad una "se però parlate in inglese è meglio" (questo a prescindere dalla lingua con cui sono state prodotte le slide, per fortuna!).
Aiutooo!!! :)
C'è un solo particolare: io NON ho un cellulare! (è vero, così come non porto orologio, e poi ogni 5 settimane mi faccio 2500 Km di viaggio senza alcuno strumento contro gli imprevisti!!!!)
Io dovrei venire in treno e dovrei essere alla stazione per le 8.15 circa, perciò credo di poter essere al CINECA prima delle 9.00
:)
Ciao
Federico
Originariamente inviato da flisi71
[B]C'è un solo particolare: io NON ho un cellulare!
:eek: :eek: :eek: :p
io credo di venire in macchina e arrivare direttamente al cineca... sperando di non trovare troppo traffico
Allora potremmo fare così: quando arrivo provo a chiamarvi e ci diamo un punto di incontro lì dentro. Ok?
Ciao
Federico
P.S. Se magari in PVT mi mandate il vostro numero di cellulare....
rejected
25-11-2002, 14:46
Ok. Per me sta bene...
Magari ci troviamo davanti all'ingresso del Cineca x le 9.00...
<rejected>
bene, grazie innanzi tutto delle Vostre risposte.
Si potrebbe fare così, alle 9.00 all'ingresso del CINECA.
x rejected: non ti invio il mio numero di cellulare perchè NON ce l'ho!
:)
Ciao
Federico
rejected
27-11-2002, 00:32
A due soli giorno dall'evento, ho scoperto di dover scrivere anche l'articolo per i proceedings: in pratica ho dovuto condensare e tradurre in inglese il minipaper...
In ogni caso parlerò in italiano usando slide in italiano... :)
Sono distrutto...
Avete novità?
Rimaniamo quindi sull'idea di incontarci all'ingresso, verso per le 9?
Per me sta bene.
Ciao e grazie ancora...
<rejected>
Per me va bene trovarci all'ingresso verso le 9.00, magari nei pressi del banco registrazione (ammesso che ci sia!):)
Anzi meglio: appena arrivo lì cerco un punto di riferimento ben visibile e provo a telefonarvi. Ok?
Ciao
Federico
rejected
27-11-2002, 16:43
Finito... Anche l'articolo è pronto...
In 2 ore oggi io ed un mio amico abbiamo riconvertito il cluster Bewulf dell'Uni (3 dual Atlon XP nuovi di zecca) a Openmosix.
Era talmente contento che mi ha chiesto di ringraziare l'autore di Openmosix... :)
Posso confermare che Openmosix batte Bewulf senza problemi ed inoltre è un gioco da bambini gestirlo...
Ci vediamo domani,allora...
Byez.
<rejected>
io spero di riuscire a venire... oggi ho sbattuto via tutta la giornata a far nulla perchè sta città con un po' di pioggia è diventata un incubo... c'ho messo 1 ora ad arrivare a Milano e abito a 3 km da Milano :eek: :mad:
Ora guardose trovo un treno comodo perchè con tutta sta pioggia con la macchina non mi fido molto...
ragazzi io purtroppo non ce la faccio, troppi casini a casa... mando un sms a rejected visto che mi sa che nessuno di voi leggera entro domani...
:(
Uzi[WNCT]
28-11-2002, 11:41
Posso fare na domanda NIUBBA su Mosix e compagnia bella? :p
E' Mooooooooooooooooooooooooooooooolto niubba però! ;)
Uzi[WNCT]
28-11-2002, 11:48
La fo subito.... :p
Allora, avete presente i programmi di grafica 3d? (LightWave, 3D studio max....) Orbene, sono tutti programmi che occupano tantissima CPU e tipicamente supportano + processori PER RENDERIZZARE UNA SCENA SINGOLA.
Secondo voi, usando mosix (o qcsa di simile) si potrebbe diminuire il tempo di calcolo di una scena, ripartendo i calcoli sui vari pc connessi in rete??
TEORICAMENTE, da quello che ho capito, dovrebbe essere possibile "far vedere" al programma un PC con CPU multiple, in automatico........ sbaglio? (mi sa di si.. :p)
ciau e graz per le eventuali risposte!!!!
In linea teorica si... in pratica no perchè quelli dovrebbero essere tutti programmi multithreda e mosix al momento non è in grado di migrarli su latre macchine...
Uzi[WNCT]
28-11-2002, 11:59
uhmmm...... azzz...... peccato! Difatti ho ben visto che nn è una cosa che si fa.. lo farebbero tutti. :)
Ma di preciso mosix riesce a migrare "solo" processi quindi???
per ora si... i thread sono "oggetti" un po' critici in quanto quelli di uno stesso processo condividono spazio di indirizzamento, descrittori dei file, ecc... poi l'implementazione di linux è piuttosto particolare e non c'è modo di riferirsi ad un singolo thread di un processo, dato che il processo in se non esiste (o quasi) ma è solo identificato da 1 o + thread che condividono lo spazio di indirizzamento.
Uzi[WNCT]
28-11-2002, 12:10
capito...... ma allora, nn è che un cluster aumenti la potenza di calcolo (come avevo capito io alla buona), ma rende + "omogenea" la potenza. In pratica si riesce ad eseguire i programmi su tutti i PC evitando il "collassamento" di uno solo.
Diciamo che si riesce a creare un multitasking fenomenale, indipendente dall' HW sul quale sono davanti fisicamente....
beh il cluster viene visto come una macchina sola... in definitiva viene fuori una grossa macchina multiprocessore, a patto di creare software multiprocesso e non multithread...
Uzi[WNCT]
28-11-2002, 12:19
già.. ma bisogna scriverlo ex-novo mi sa..... di già esistente si trova più che altro multithread :(
(cmq interessantissima sta roba... maròòòòòòòò!!! Metto su un cluster fra portatile scarsissimo e pc + prossimo muletto :p)
rejected
28-11-2002, 20:30
Sono strastanco,ma piacevolmente soddisfatto...
Ho visto cose che voi umani... :)
Dual opteron con 1 GB di DDR con UnitedLinux... Che storia....
Tornando alle cose serie:
Rispondo a Uzi[WNCT]:
Un cluster è un insieme di macchine che lavorano insieme per risolvere problemi che richiedono enormi risorse.
Allo stato attuale OpenMosix può migrare (=distribuire il lavoro sui vari nodi) solo processi.
Tuttavia programmi di rendering come Povray, nella versione PVM/MPICH ( librerie per il calcolo parallelo) sfruttano Openmosix e le prestazioni sono davvero interessanti...
Tuttavia oggi, Moshe Bar (l'autore di Openmosix), al Workshop ha detto che entro il prox anno anche thread, short job,... migreranno (ha detto che ha già un prototipoin laboratorio funzionante che rilascerà entro 5-6 mesi).
Ciò significa che tutti i problemi di distribuzione con Opemosix cadranno... (o almeno si spera...)
Se ti va, dai un occhio al mio sito.
E' più in basso, nella "signature".
Vo a riposare... :)
Poi nei prox giorni posterò tutto x benino...
Per Alexmaz: mi spiace che tu non ce l'abbia fatta a venire. E' stata un gran bell'evento... Cmq non disperare: ne faranno dgeli altri... :)
Per Flisi: sono distrutto. Tu sei ancora in piedi? :)
Mi ha fermato un altro tizio a chiedermi di Java...
<rejected>
Ciao rejected, meno male che sei distrutto, ma appena tornato a casa ti metti subito a postare?
Scommetto lo fai per far morire di invidia alexmaz?:D
A me è piaciuto molto, tutti interventi molto interessanti; Moshe Bar estremamente gentile e disponibile con tutti. Davvero un grande!!
Poi c'era anche Neo, al quale abbiamo chiesto quando esce il seguito di Matrix!
A me ha impressionato anche l'intervento di Arcangeli sulle nuove features del kernel Linux.
E poi ciliegina sulla torta il server Dual Opteron su rack 1U, con 2 CPU a 1,4 GHz e 4 GB RAM.
Tutto davvero interessante.
x alexmaz e Uzi[WNCT]: come vi ha già detto rejected, Moshe Bar ci ha confermato che entro breve uscirà una versione di OpenMosix con il supporto della memoria condivisa, già adesso funziona nel suo laboratorio e fa migrare in modo trasparente istanze Oracle, che attualmente sono prese come esempio di processi che NON migrano affatto. Ci sono però degli inconvenienti, quali l'alto costo della migrazione da un nodo all'altro e sopratutto la bandwith necessaria per mantenere la coerenza delle pagine di memoria su tutti i nodi.
Ma sta studiando nuovi algoritmi che dovrebbero ridurne il costo computazionale.
Quindi il futuro si annuncia roseo.
P.S. prima del suo intervento rejected era nervosissimo, perchè a tutti gli altri Moshe Bar e/o Arcangeli avevano fatto delle domande, e aveva paura che ne facessero anche a lui e che non fosse in grado di rispondere; INVECE il suo intervento è stato brillante e spigliato, e ha risposto con prontezza alle domande che gli hanno rivolto. BRAVO!
x rejected: salutami anche la tua morosa, davvero carina e acuta!!!!
Ciao
Federico
Uzi[WNCT]
29-11-2002, 09:41
figatissima..... se sta roba va in porto ...... cambia il modo di usare i PC... slurp!
Cmq a me (come già detto) pare "impossibile" che si possa far migrare i thread. E' proprio la larghezza di banda necessaria e pure il "ping". A questi livelli (e con processori moderni, diciamo da almeno 2 ghz) mi pare impossibile che una rete convenzionale (anche ad un gigabit) riesca a traferire una mole di dati tale, in pochissimo tempo. :)
Cmq resto fiducioso.... se il tipo ha detto che funziona...... SLURRRPPP!!!!! :p
rejected
29-11-2002, 20:24
Per Flisi.
La girl ricambia il saluto: gli stai simpatico... Sono geloso! :)
Quanto al resto, dopo aver guidato per 450KM e aver parlato al Workshop, sono rimasto in piedi fino all'1....
Si vede che sono un informatico...
Stakanovista x natura... :)
Per todos.
Mi raccomando se siete interessati a OpenMosix, iscrivetevi alla mailing di democritos (www.democritos.it -> mailing list -> openmosix).
Qui dovrebbero riunirsi tutti gli utenti interessati... Ogni tanto, forse, farà capolino anche Moshe Bar...
Matrix era un grande (come tutti gli altri)...
<rejected>
rejected
01-12-2002, 09:19
Salve a todos
Ieri notte (intorno alle 2) sono riuscito finalmente a far funzionare una versione user-space dei PThread su Openmosix (libreria multipiattaforma FSU-Pthread di Frank Mueller).
Una applicazione multithread è stata migrata con tutti i suoi thread da un
nodo all'altro senza toccare una sola riga di codice.
Il programma che ho usato (il mio solito ptDiv.c) ha una variabile condivisa fra i vari thread
(protetta da mutex).
>> E' stato possibile migrare l'applicazione intera con i suoi pthread
"appesi", non i singoli thread! <<
Ciò non toglie che la cosa, seppur limitata, mi sia particolarmente
gradita... :)
Per maggiori spiegazioni, date un'occhiata a
http://filibusta.crema.unimi.it/mosix/fsuthreads_e_openmosix.htm
In questo momento sto facendo i benchmark: appena disponibili li pubblicherò
sul sito (i test preliminari sono molto interessanti,IMHO).
Fatemi sapere che ne pensate.
<rejected>
Ciao rejected,
come stai?
Ti leggo solo adesso, e corro subito a dare una occhiata e ad iscrivermi.
:)
Ciao
Federico
rejected
02-12-2002, 13:47
Ciao Flisi.
Direi che sto bene...
Mi sono ripreso e mi sono subito rimesso a smanettare su Openmosix... :)
Come sta la girl? Spero bene!
Tra l'altro ho avuto conferma che (finalmente) in Uni avremo un cluster Openmosix/Beowulf _serio_ (3 dual Athlon MP 1900+ e 3 Athlon 1 Ghz).
Io ed un mio amico (che farà la tesi proprio su questo progetto) stiamo progettando il tutto per il nostro professore di Fisica.
Fin da adesso posso confermare che Openmosix può solo migliorare (o,al peggio, uguagliare) le prestazioni di Beowulf/MPI...
Inoltre, di notte, sto testando le varie librerie in user-space su OM...
Pensa che c'è un mio amico che vorrebbe provare a distribuire Maya+client su OM... :)
Ciao.
<rejected>
Ciao rejected, come stai?
Sono contento per te che in Uni ti installino un bel cluster dedicato per sperimentare; magari l'avessi io!!!
:)
Io mi diletto con OpenMosix e in effetti ho interessi nel campo grafico, dove con PovRay avevo visto che impostando un batch di immagini statiche da renderizzare, queste venivano facilmente distribuite nel cluster, ma non ho mai provato con Maya perchè...non so usarlo!
Certo che per fare delle prove mi basterebbe utilizzare i file di esempio e tutorial inclusi!
Quasi quasi ci provo uno di questi giorni.
Ciao
Federico
Uzi[WNCT]
03-12-2002, 09:29
Per linux c'è pure XSI..... :D:D
Difatti a me interessava molto sto thread proprio per cercare di diminuire i tempi di render... :D
(cmq è un casino lo stesso, e richiede una risoluzione del desktop a 1280x1024 :()
Si l'ho intercettato, ma non l'ho installato perchè non mi riesce, mi manca qualcosa.
Ciao
Federico
rejected
03-12-2002, 22:15
....è che non diffondono i codici sorgenti... :)
Scherzi a parte, XSI ha dei client-slave cui delegare parte del rendering?
Non ho XSI per Linux e non posso provare. Sorry... :)
Cmq mi informo (conosco chi può darmi informazioni in questo senso): se scopro qualcosa, posto subito...
Per Flisi.
La girl ringrazia x i complimenti e ti saluta...
Capisco la tua situazione in campo lavorativo: parlare con i profani in campo informatico spesso è frustrante... Non è questione di superiorità tecnica/mentale/culturale/...: semplicemente ci sono persone che non sanno e non volgliono imparare alcunchè perchè "tanto c'è il tecnico che risolve tutto: è pagato proprio per questo!". E spesso a tutto ciò si aggiunge una certa aria di arroganza da parte dei "clienti/utenti"...
Byez.
<rejected>
Uzi[WNCT]
03-12-2002, 22:41
uhmmm,...... ammetto che l'ho provato per 30 minuti e basta... :p
Anche perchè richiede per forza la risoluzione di 1280x1024 e al mio monitor nn va molto bene ;)
Cmq c'era un "client" ed un "server"..... resta il fatto che davvero nn ho provato. Inoltre (cosa importantissima) io avevo la versione per Windows, quindi nn so di preciso che cosa ci sia nella versione per Linux... :(
Al 90% ci sarà un "client" per delegare il render su altre macchine, ma credo sia sempre per una animazione e nn per il singolo frame.
Devo ammettere che nn sono informatissimo su XSI, dato che principalmente mi diletto con LightWave e quest ultimo è solo per Win...
Se volete vedere che ci fo con LW, andate a fare un salto nella sezione "computer grafica" :cool: :D ;)
Ciao ragazzi, mi spaice parecchio di non essere venuto a Bologna, ma purtroppo non ce la facevo proprio :(
parlando di openMosix ho notato una cosa: io lo uso anche sul pc che utlizzo e mi pare di aver notato un forte peggioramento delle prestazioni di I/O sul filesystm (ext3) sia con un normale tar che con samba... per esempio mentre scompattava i sorgenti di Mozilla 1.2.1 il pc era semi paralizzato, cosa mai successa prima... qualcuno conferma?
ciao :)
AnonimoVeneziano
09-12-2002, 17:32
Raga, ce la fate a spiegarmi meglio sta storia del mosix? Cioè , vorrei provare a mosixare (openmosixare:D ) 2 Computer (o forse 3) che ho qua in casa, 1 PIII 1000 (e forse un 600) e un Athlon 2400+, si può? In cosa avrei miglioramenti, calcolo distribuito?
Grazie
Ciao
rejected
09-12-2002, 22:26
Ciao, AnonimoVeneziano.
Dunque dunque...
Openmosix è un cluster ad alte prestazioni che si integra nel kernel di Linux (è una patch di poco più di 100k righe di codice).
Oltre alla patch sono disponibili una serie di utility (i più importanti e migliori sono gli userland tools e Openmosixview) per amministrare il cluster.
Come ben saprai ogni programma in esecuzione è un processo, ossia un contesto di esecuzione: parte di un processo è in kernel space (ossia utilizza chiamate di sistema o cmq istruzioni privilegiate) e parte è in user-space (ossia sfrutta istruzioni non privilegaite e quindi, teoricamente, non _totalmente_ vincolate al sistema su ciui il programma è in esecuzione).
Orbene, Openmosix è in grado di distribuire (si parla tecnicamentedi "migrazione" dei processi) la parte di un processo in user-space da una macchina (nodo) del cluster ad un'altra.
Perchè fare ciò?
Semplice! Se una macchina è sovraccaricata il fatto di spostare (distribuire) il calcolo su altre macchine è una cosa intelligente e se è opportunamente gestita (come nel caso di Openmosix) è molto efficiente.
A differenza di altre soluzioni di clustering, Openmosix:
- è in grado di bilanciare il carico dinamicamente e autonomamente: ciò significa che se un nodo è carico e OM vede che c'è un altro nodo meno occupato (o addirittura nullafacente, idle) sposta da solo il lavoro su quest'ultimo nodo. Tutto ciò in maniera traspararente all'applicazione e anche all'utente (in ogni caso l'utente può intervenire manualmente e decidere come più gli aggrada). Tutto ciò viene fatto attraverso algoritmi trattai dal campo economico (leggi della domanda e dell'offerta,...).
- è facilissimo da installare e amministrare è un gioco da ragazzi
- è opensource e puoi giocare col codice... :)
- gestisce nodi in maniera hotswap: puoi inserire e rimuovere i nodi mentre gli altri sono in esecuzione.
- i nodi possono essere macchine anche totalmente diverse (io ho, per esempio, un cluster con un PIII e un AthlonXP)
- scala in maniera egregia (ossia più nodi metti, più le prestazioni aumentano).
- ...
Nota bene che Openmosix è un fork (ossia un progetto derivante,ma ora distinto) da Mosix.
Mosix un anno fa era ancora opensource, poi ha cambiato licenza ed è quindi sorto un nuovo progetto, Opensmoxi appunto, che intende continuare lo sviluppo, opensource, del progetto.
Per la cronaca: Mosix è un progetto nato negli anni '70 e prima di Linux è giunto su BSD.
Attualmente Openmosix non può:
- migrare singoli thread da un nodo ad un altro (questa fetaure è attesa per il 2003).
- migrare processi che condividono memoria (shared memorory): anche questa feature è attesa per il 2003.
- quanto alla migrazione di programmi multithread (come se fossero un unico processo), sono riuscito a migrarne una. Ma se usi le librerie di thread di default di Linux (i famosi PThread/LInuxThreads) la cosa non funziona... :)
In ogni caso, se sei ineterssato, ti consiglio il sito ufficiale:
openmosix.sourceforge.net
Se ti va di dare un'occhiata al mio sito (in italiano), l'indirzzo è nella mia firma, qui sotto. Fine messaggio pubblicitario... :)
Spero di essere stato abbastanza chiaro e non averti confuso... :)
Tieni conto che OM è un progetto maturo e sicuramente questa breve panoramica/introduzione che ti ho fatto è riduttiva e incompleta.
Ciao a tutti.
<rejected>
PS: per tutti. Se lanciate due ripping/encoding distinti con mencoder, Openmosix parrebbe muoversi... :)
PS2: se vi interessa iscrivitevi senza timore esiste alla mailing list ufficiale italiana di opensmosix. La pagina è:
http://www.democritos.it/mailman/listinfo/openMosix
AnonimoVeneziano
09-12-2002, 22:39
Allora, fammi capire, quindi Mosix per ora non è in grado di migrare un singolo Thread (che ne so, seti ad esempio) in modo da distribuirne le prestazioni sui 2 PC, ma mettendo il caso che avvio 2 Sessioni di seti migra la seconda sul 2° PC, ho detto bene? Ho detto male?Ci sono applicazioni nate appositamente per mosix?
Ciao
Uzi[WNCT]
09-12-2002, 23:55
mi ispira sempre di più sta cosa....... :p
Sto per fare un "pc muletto" con un duron 700 usato..... avete già capito che fine farà??? ;);)
Supponiamo che io lanci:
1) mozilla (x2) ;)
2) un paio di shell
3) IlClientDiPostaQuelloFigoCheNonMiVieneIlNome
4) irc (kvirc supponiamo)
5) gnomecu o licq
6) un qualche clone di Winamp...
7) qcsa per gestire i files
secondo voi cominciano a migrare i processi??? Il bello è che sarebbe tutto dinamico, spengo il "muletto" e mi torna tutto sul desktop....... bellissimo...... :p
rejected
10-12-2002, 12:43
Per AnonimoVeneziano
1) Seti in Linux è un unico processo. Di fatti è possibile migrarlo tranquillamnete da un nodo ad un altro. Se hai 2 pc, lancia su una macchina 2 o più istanze e vedrai che qualcuna sarà spostata.
2)Per la cronaca, Seti sotto Windows è multithread, ma ha un problema.
Stando alle info datemi da un mio amico (che ne sa tanto,ma davvero tanto) su un SMP (macchina multiprocessore) "occupa tutte e due le CPU al 100%,ma le performance non aumentano rispetto ad un mono perchè la seconda sembra che non faccia nulla..."
3)Guarda sul sito di Openmosix, "Addons" per le applicazioni compatibili...
Per Uzi[WNCT]
Se la tua macchina è carica e la causa sono processi molto impegnativi (qualunque processo che non sia _troppo legato_ al sistema di partenza va bene), Openmosix entrerà in azione automaticamente e deciderà se spostare qualcosa e come.
Tieni conto che cmq puoi sempre intervenire manualmente e tentare di forzare la migrazione ad altri nodi.
Byez.
<rejected>
qweasdzxc
10-12-2002, 12:51
Originariamente inviato da rejected
[B]Per AnonimoVeneziano
2)Per la cronaca, Seti sotto Windows è multithread, ma ha un problema.
Stando alle info datemi da un mio amico (che ne sa tanto,ma davvero tanto) su un SMP (macchina multiprocessore) "occupa tutte e due le CPU al 100%,ma le performance non aumentano rispetto ad un mono perchè la seconda sembra che non faccia nulla..."
ma di recente sta cosa? perche mi ricordo tempo fa che il client testuale sotto win era assolutamente monothread, e per usare 2 cpu se ne facevano partire 2.
il client grafico invece era una porcata, occupava 2 cpu e andava come una sola...
rejected
10-12-2002, 18:24
Per qweasdzxc
<QUOTE>
ma di recente sta cosa? perche mi ricordo tempo fa che il client testuale sotto win era assolutamente monothread, e per usare 2 cpu se ne facevano partire 2.
il client grafico invece era una porcata, occupava 2 cpu e andava come una sola...
</QUOTE>
Esattamente: 2 cpu, una sola running se si usa il client grafico...
Hia ragione: la versione non grafica è monothread.
Non uso la versione Win di Seti da tempo: controllo ora se ci sono news ed eventualmente le posto... :)
Byez.
<rejected>
Uzi[WNCT]
11-12-2002, 12:03
una domandina pratica: che rete ci vuole per creare un cluster piccolo? (diciamo 3 pc al massimo).
Avrei a disposizione solo una lan a 10mbit su un hub (quindi il traffico si propaga...). Potrebbe andar bene lo stesso?
ciauz
Certo, anch'io avevo iniziato con un hub 10 Mbit, è senz'altro sufficiente per provare OpenMosix, magari non ti aspettare prestazioni estreme.
Ciao
Federico
Uzi[WNCT]
11-12-2002, 12:10
bene bene.... già qcsa!!! (son sempre + convinto...... chi mi vende a pochi soldini un case ATX che metto su il secondo PC?? :p:D)
Macchè un case nuovo, ti basta un alimentatore!
:)
Ciao
Federico
Uzi[WNCT]
11-12-2002, 12:14
ce l'ho ali, ma i miei mi spaccano se lascio un pc tutto smontato in giro!!! :p:p
Almeno col case, monto tutto e lo "nascondo" sotto al tavolo! ;)
(tanto con ssh sono apposto, col cluster e dsh vado meglio ancora! Hhhihihihi ;))
rejected
11-12-2002, 22:34
Openmosix non è schizzinoso quanto a risorse: una 10Megabit va tranquillamente per un uso "domestico". La 10/100 comincia ad avere senso se i tuoi programmi sfruttano tantissimo la rete e/o fanno molto I/O: se un programma che fa molto I/O è stato spostato da un nodo ad un altro, l'I/O sarà notificate/inviato via rete al nodo di partenza (home node). In questo caso avere una rete "che spinge" ha un senso.
Posso dirti fin da ora che l'unico caso in cui ho visto la reale necessità di una Gigabit è su un cluster con applicazioni scientifiche impegnative come Amber (programma di fisica particellare/...).
Siccome questo programma scrive parecchio (nell'ordine di decine di GB "a botta"), la rete è fondamentale per trasferire celermente le info al nodo di partenza (la 10/100 non ci stava dietro ed il mio prof di Fisaca era disperato... :) ).
Paradossalmente avere una rete potente può essere un freno in determinati casi.
Al Cineca hanno dimostrato che se utilizzi una Mirinet (è una casa che produce schede costosissime dotate di una latenza veramente infima e una banda mostruosa costante di qualità superiore) Openmosix potrebbe confondersi e continuare a migrare ciclicamente un processo. Per intenderci: OM sposta un processo poi si accorge che un altro pc ha una situazione migliore e lo risposta... e continua così...
Lo fa perchè i pc hanno schede a latenza bassissima e rispondono subito alle richieste per le statistiche. Più ricalcoli delle statistiche ci sono in un secondo, più aumenta la possibilità che OM intervenga e sposti qualcosa.
Con le schede Ethernet 10/100/1000 ciò non succede (hanno una latenza enorme rispetto alle Myrinet): scelto un nodo, prima di ricalcolare e ottenere le statistiche globali del cluster ce ne vuole: risultato il numero di ricalcoli dlele statistiche per secondo è inferiore e il cluster ha tempo di prendere poche decisioni (ma possibilmente quelle buone). :)
Morale della fiaba #1: la 10 Mbit non inganna OM -> usala pure con tranquillità (alla peggio opta per una 100 o una 1000).
Morale della fiaba #2: non comprare le Myrinet se vuoi giocare con OM (almeno per il momento... :) ).
Spero di essermi spiegato bene. :)
Byez.
<rejected>
AnonimoVeneziano
11-12-2002, 22:42
Originariamente inviato da flisi71
[B]Macchè un case nuovo, ti basta un alimentatore!
:)
Ciao
Federico
Io stavo pensando a una soluzione diskless via Ethernet, è possibile? (ora, scusate ma in quanto a soluzioni di questo tipo sono ankora pivello:) ) in pratica Mobo + Ali + .......niente!:D(ethernet ovviamente e Skvideo)
Ciao
Uzi[WNCT]
11-12-2002, 23:01
x rejected: iiiiiiiihhhhhh... chebbbbbbeeeellllooooo!!! Appena trovo il case..... :rolleyes: va a finire che monto tutto su roba "volante" ;)
rejected
11-12-2002, 23:19
per Uzi[WNCT]
Non dirlo a me...
Mi sono appena scaricato la nuova versione di OM (per il kernel 2.4.20) e lo ricomplo.
per AnonimoVeneziano
OM e nodi diskless?
Esiste già e si chiama PlumpOS (ClumpOS per Mosix non open).
E' una minidistro di pochi mega che viene caricata e rimane in Ram alla stregua di Knoppix. Automaticamente via dhcp si auto-aggiunge al cluster divevendo a tutti gli efftti un nodo di OM perfettamente funzionante. Ovviamente c'è bisogno di almeno un nodo _completo_ e disk-provided da cui lanciare i programmi, prelevare file in input e salvare eventuale output sempre su disco.
Pensa a n macchine Win convertite on-the-fly a OM senza toccarne gli HD. Pensa al fatto che se n macchine non riescono a fare un lavoro, tu ne puoi prendere altre e aggiungerle e rimuoverle dinamicamente al cluster senza toccare niente se non la Ram... :)
Fico, nevvero?
I miei amici sono rimasti con la mascella bloccata e la bava alla bocca quando all'epoca (1 anno e 1/2 fa) ho mostrato loro ClumpOS...
------------------
L'angolo del trucco...
KERNEL RECOMPILATION CON OM
Per ricompilare il kernel di Linux, usate OM !!! :)
E' un vecchio trucco che ho provato tempo fa e che ora qualcuno ha opportunamente documentato... :)
Leggete le ultime righe di http://howto.ipng.be/openMosixWiki/index.php/work%20smoothly
(dove si parla di make -j num_jobs) e divertitevi !!!
Spero vi possa interessare...
Byez.
<rejected>
Uzi[WNCT]
15-12-2002, 10:04
io ho quasi trovato il case..... forse per la settimana prox....... preparati Rejected, che ti romperò le @@ !!! ;);) :muro:
rejected
15-12-2002, 12:21
Salve a tutti.
Sto iniziando un nuovo progetto (tipo client-server) per ottenere e mostrare via web o via programma standard lo stato di Openmosix.
Il progetto è così costituito.
1) Un demone scritto in Java da eseguire su uno qualunque dei nodi del server che fornisce le informazioni via TCP sullo stato del cluster. Pur essendo scritto in Java, l'ho ricompilato col GCJ (Gnu Compiler for Java) e ho ottenuto un eseguibile (quindi niente classi bytecode) perfettamente funzionante: non è più necessario avere una Java Virtual Machine!
Stato attuale: completato al 60%.
Supporta: connessioni multiple (più client serviti contemporaneamente), facilmente estensibile, pesantemente commentato (per motivi didattici) e di facilissima comprensione,...
2)Applet Java, eseguita dentro ad un browser compatbile con Java2, che recupera dal demone le info sul cluster e le mostra graficamente _in real time_. Ho già recuperato un'apposita classe per generare i grafici (vedere http://chart2d.sourceforge.net). Stato attuale: 30%.
Sto mettendomi d'accordo con un mio amico: se possibile la applet ricorerrà alle OpenGL (Java supporta questa libreria: WOW!!!) per un maggiore effetto scenico :) .
Chi vuole partecipare come betatester e/o come sviluppatore, faccia un fischio... :)
Per la cronaca, manco a farlo apposta, ieri è sorto un progetto che fa più o meno le mie stesse cose, ma richiede che su un nodo sia presente apache, modulo PHP e Openmosxiview installato e configurato (http://laurel.datsi.fi.upm.es/~rpons/openmosix/), inoltre non è real time, e mostra i dati come immagine statiche da refreshare. Per il resto è graficamente eccelso! :)
<rejected>
PS per Uzi[WNCT]: presente! Conta pure su di me...
rejected
16-12-2002, 23:01
Per favore, se rispondete, scrivete sulla nuova discussione chiamata "Openmosix: discussione." che ho aperto.
Così almeno evitiamo che altri utenti, potenzialmente interessati, fraintendano leggendo del minipaper.
Grazie a tutti.
<rejected>
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.