Eκτέλεση του Alice σε cluster. Παίζει;

Ξεκίνησε από fupat2, 10 Φεβ 2015, 08:30:40 ΜΜ

« προηγούμενο - επόμενο »

fupat2

#15
Παράθεση από: alkisg στις 27 Φεβ 2015, 12:07:38 ΠΜ
Ωραία, περιμένω να μας στείλεις τον σχετικό κώδικά σου για την υποστήριξη αυτών των διανομών ή στο IRC κανάλι #ltsp ή στην ltsp-developers mailing list.

Πριν το κάνω αυτό πάντως θα δοκιμάσω το KestrelHPC .

Υποτίθεται ότι κάνει την δουλειά που θα έκανε o συνδυασμός PelicanHPC/LTSP

Αν δουλέψει, δεν υπάρχει λόγος να ασχοληθώ με κώδικα.

Στο κάτω κάτω πρώτος στόχος μου είναι να μπορέσω να κάνω μάθημα με το σαράβαλo εργαστήριο που έχω, στήνοντας ένα cluster που ίσως βοηθήσει στο να τρέξουν βαριά προγράμματα (ακόμα και αν δεν είναι το alice)

Δεν έχω ως  πρώτο στόχο να γίνω developer του LTSP, την στιγμή που initially δεν φαίνεται να υποστηρίζει διανομές με clusters.
Θα ασχοληθώ με LTSP μόνο αν δεν βρω άλλη έτοιμη cluster λύση.

Παράθεση από: alkisg στις 27 Φεβ 2015, 12:06:44 ΠΜ
Αύριο θα ξεχωρίσω αυτά τα μηνύματα σε ξεχωριστό θέμα ώστε στο παρόν topic να μείνουν μόνο τα μηνύματα που πραγματικά αφορούν το "Πρόβλημα με το Alice 3 σε thin clients".

To KestrelHPC χρησιμοποιεί thin clients, και θα ήταν ενδιαφέρον να δούμε αν το Alice τρέχει (ή δεν τρέχει) σε αυτό και αν έχει (ή δεν έχει) βελτίωση στην απόδοσή του.
Οπότε αν με μετακινήσεις , καλό είναι να μετονομάσεις αυτό το θρεντ σε "Πρόβλημα με το Alice 3 σε thin clients του Ubuntu/LTSP"

Ενώ το καινούργιο θρεντ που θα με μεταφέρεις, ονομάσετο "(Θεωρητικά) προβλήματα με το Alice. Τρέχει γρηγορότερα σε thin clients ενός cluster; "
Η παιδεία είναι άσκηση ελευθερίας, που λυτρώνει τόσο τον μαθητή όσο και τον παιδαγωγό από μια δίδυμη υποδούλωση. Την υποδούλωση της σιωπής (που αφορά κυρίως τον μαθητή) και την υποδούλωση του μονολόγου (που αφορά κυρίως τον παιδαγωγό).

alkisg

Παράθεση από: fupat2 στις 27 Φεβ 2015, 12:11:14 ΠΜ
Ενώ το καινούργιο θρεντ που θα με μεταφέρεις, ονομάσετο "(Θεωρητικά) προβλήματα με το Alice. Τρέχει γρηγορότερα σε thin clients ενός cluster; "

Επειδή το Alice δεν τρέχει σε thin clients εντός cluster (θα το καταλάβεις αν ποτέ το προσπαθήσεις), δεν μπορώ να ονομάσω έτσι το θέμα, οπότε του έδωσα τον τίτλο που βλέπεις.
Όταν θελήσεις άνοιξε δικά σου θέματα και ονόμασέ τα όπως αγαπάς.

fupat2

#17
Παράθεση από: alkisg στις 27 Φεβ 2015, 08:11:22 ΠΜ
Επειδή το Alice δεν τρέχει σε thin clients εντός cluster (θα το καταλάβεις αν ποτέ το προσπαθήσεις), δεν μπορώ να ονομάσω έτσι το θέμα, οπότε του έδωσα τον τίτλο που βλέπεις.
Όταν θελήσεις άνοιξε δικά σου θέματα και ονόμασέ τα όπως αγαπάς.

1) Όσον αφορά τα Multi system Image clusters.

Στήσε το openmosix-linuxpmi, τρέξε ένα βαρύ πρόγραμμα σε java και δες τα βαριά process να κάνουν migrate από μηχάνημα σε μηχάνημα. Αυτό δεν το λέω θεωρητικά, τo έχω δοκιμάσει, και προκαλώ οποιονδήποτε να το επιβεβαιώσει ή να το διαψεύσει.

Το alice είναι java.
Άρα θα γίνεται migrate οποιοδήποτε βαρύ process.  Μάλιστα στο Linuxpmi (η συνέχεια του openmosix) εξετάζουν να γίνονται migrate και τα threads.

Το alice είναι όμως και opengl.
Αν δεν παίξει, αυτό θα είναι γιατί το opengl του alice απαιτεί Kernel 3.χ (ενώ το openmosix είναι σε Kernel 2.x) και γιατί θα κολάει γενικά το opengl (που κατά βάση είναι machine dependant library). Το πρώτο πρόβλημα ίσως λύνεται με αλλαγή του cluster software και το δεύτερο ίσως λύνεται με κάποια από τα libraries που βοηθούν στο να γίνεται virtual το opengl και να  μοιράζεται ο φόρτος του στο cluster.

2) Όσον αφορά τα single system image cluster.

π.χ. http://www.kerrighed.org/wiki/index.php/Main_Page

Δεν έχω στήσει ποτέ , αλλά δεν καταλαβαίνω γιατί δεν μπορεί να παίξει οποιαδήποτε εφαρμογή, την στιγμή που ολόκληρο το cluster εμφανίζεται στον τελικό χρήση ώς ένα ενιαίο μηχάνημα.
Η παιδεία είναι άσκηση ελευθερίας, που λυτρώνει τόσο τον μαθητή όσο και τον παιδαγωγό από μια δίδυμη υποδούλωση. Την υποδούλωση της σιωπής (που αφορά κυρίως τον μαθητή) και την υποδούλωση του μονολόγου (που αφορά κυρίως τον παιδαγωγό).

fupat2

#18
Παράθεση από: alkisg στις 26 Φεβ 2015, 06:27:43 ΜΜ
Σόρρυ αλλά δεν έχω χρόνο να σου εξηγήσω π.χ. γιατί το cluster δεν μας βοηθάει για 3D μέσω δικτύου, ή γιατί το DISPLAY έτσι κι αλλιώς είναι πάντα EXPORTed, αλλιώς δεν θα είχαμε καθόλου γραφικά, ούτε 2D... οπότε μην προσπαθήσεις να πιάσεις τεχνική συζήτηση με μένα, αρνούμαι, απλά να προφυλάξω τους συναδέλφους ήθελα.

Όταν κάνεις export display, τότε χρησιμοποιείς την CPU και όλα τα resources του server σου, αλλά βεβαίως χρησιμοποιείς την GPU του thin client. Αυτό σημαίνει αρχικά ότι πρέπει να έχεις καλή κάρτα γραφικών στον thin client, και ως εκεί έχεις ένα δίκιο σε αυτά που λες για το export display.

ΌΜΩΣ και το Limitation της μικρής GPU στο thin client μπορεί να ξεπεραστεί αν βάλεις μια ενδιάμεση βιβλιοθήκη, ξεγελάσεις το πρόγραμμα όσον αφορά τους 3D υπολογισμούς του opengl και αναθέσεις στο server (ή στο cluster) να κάνει αυτούς τους υπολογισμούς, και καταλήξεις τελικά να εμφανίζεις πρακτικά μια κινούμενη εικόνα video στο thin client και όχι να κάνεις το 3D rendering με την GPU του.

Για περισσότερες πληροφορίες δες και αυτό το άρθρο:
http://www.linuxfocus.org/English/January2002/article222.shtml

ποιό συγκεκριμένα αναφέρει για την opengl (που μας αφορά, αφού αυτή χρησιμοποιεί το alice)

ΠαράθεσηOpenGL
While the networking possibilities of the X Window System are very good, the graphics are a bit slower due to the fact that you send the data over a network protocol. Normally you will not notice much difference.

Graphic intensive and fast applications such as graphic intensive games are usually based on OpenGL (Open Graphics Library) and GLX (OpenGL Extension to the X Window System). These libraries provide a hardware independent programming interface that provides direct access to 3D hardware acceleration in the graphics card. That is: the application sends the description of an object in the form of points, lines and polygons to the graphics card and all the rendering is then done inside the graphics hardware. This provides for very fast graphics.

Currently most Linux graphic card drivers (X servers) do not support hardware-accelerated GLX/OpenGL for remote applications. They do support hardware acceleration for local applications. The effect is that remotely started OpenGL applications are hardly starting at all and are really slow. An exception are the closed source NVidia drivers. They have a direct rendering interface which supports indirect rendering for remote applications

Από εκεί και πέρα, ξεκινά το ψάξιμο για το αν πράγματι μόνο οι Nvidia προσφέρουν αυτό το ενδιάμεσο rendering interface , ή αν το έχει φτιάξει και κάποιος άλλος και δεν έχει δοθεί ακόμα σε αυτό δημοσιότητα , λόγω των γνωστών στρεβλώσεων του ιδιωτικού τομέα ο οποίος σπονσοράρει κάποιους να γράφουν κώδικα που εξυπηρετεί το κέρδος ή την κατασκοπεία-έλεγχο, ενώ από την άλλη πραγματικά χρήσιμος και ωφέλιμος κώδικας αφήνεται να πεθάνει μέσα στην αφάνεια, λόγω της συνεχόμενης εξ επί τούτου αλλαγής των προδιαγραφών από τις μεγάλες ιδιωτικές εταιρίες σε συνδυασμό με την έλλειψη δημοσιότητας-χρηματοδότησης-σπόνσορινγκ που κατά βάση οι ίδιες αυτές εταιρίες προσφέρουν.

Μια προσπάθεια που αξίζει την προσοχή μας είναι αυτή που ήδη ανέφερες, η VirtualGL η οποία σπονσοράρεται από τις παρακάτω εταιρίες, με ότι αυτό μπορεί να σημαίνει για όποιον θέλει να το ψάξει παραπάνω.

ΠαράθεσηVirtualGL is an open source program that redirects the 3D rendering commands from Unix and Linux OpenGL applications to 3D accelerator hardware in a dedicated server and displays the rendered output interactively to a thin client located elsewhere on the network.

Η VirtualGL "redirects the 3D rendering commands from Unix and Linux OpenGL applications to 3D accelerator hardware in a dedicated server".

Φυσικά και είναι τεχνικά δυνατόν να κάνεις "redirect the 3D rendering commands from Unix and Linux OpenGL applications to a render cluster farm".  Ως παράδειγμα έχουμε το project του wiredGL το οποίο συνεχίστηκε και ως Chromium Project αλλά τελικά είναι νεκρό (αξίζει πάντως να δοκιμαστεί αν παίζει με το alice, διάβασε τις οδηγίες εδώ).

Είμαι λοιπόν ακόμα στο ψάξιμο για το αν τελικά υπάρχει όντως κάποιο ενεργό και σύγχρονο project που να ξεγελάει το opengl και να υποστηρίζει cluster rendering.

Τέλος όσον αφορά το network bottleneck που ανέφερες ότι θα υπάρχει σε ένα distributed rendering cluster, ένα paper που διάβασα καταλήγει:

Παράθεση... in a locally distributed rendering system, the transfer from
one GPU to the other needs to go over the CPU and the
memory, which is a limiting factor. Moreover, for distributed
rendering using a network of computers, the network speed is
a bottleneck. We argue that, under these bottlenecks, rendering
can be distributed provided that the rendering speed of a
processing unit is slow enough to compensate for the time
delay for the data transfer, either in the computer or in the
network
.

Το πόσο μεγάλο bottleneck αποτελεί το δίκτυο για να κάνουμε cluster rendering με το Alice, μπορεί να υπολογιστεί από τις ανάγκες για rendering speed που έχει το Alice. Του οποίου τα system requirements είναι:
ΠαράθεσηHardware Recommendations for Alice

    Desktop or laptop computer.   however many netbook models are designed to work well with 2D graphics but are not up to snuff when trying to deliver 3D graphics animation. We suggest trying Alice on the netbook that will be used with Alice before purchase.
    1 GB RAM (2 GB or more is recommended, but not required)
    VGA graphics card capable of high (32 bit) color and at least 1024x768 resolution (3D video card gives faster performance, but is not required)
    Sound card
    Two- or three-button mouse. The touchpad on a laptop may be used. Please note, however, that arranging 3D objects in a virtual world is easier with a mouse than with a touchpad.



Παράθεση από: alkisg στις 26 Φεβ 2015, 09:55:49 ΜΜ
Όχι δεν το θυμάμαι αλλά αν σώπασα θα ήταν για τον κλασσικό λόγο, ότι μαζί σου χρόνια τώρα δεν βγαίνει ποτέ άκρη...
Όχι! Σώπασες απλούστατα γιατί είχες άδικο. Είχες συμβουλέψει τους συναδέλφους ότι στον προγραμματισμό σε sh
Παράθεση από: alkisg
    ποτέ τα περισσότερα κενά δεν ήταν πρόβλημα.
και είχες κάνει λάθος γιατί το :
for i in 4 5 6 7 8
do
δεν είναι το ίδιο με το :
for i in 4      5     6 7 8
do

Έτσι και τώρα, αναρωτήσου μήπως η επιλογή cluster είναι καλύτερη λύση για τα εργαστήρια από αυτή του LTSP/Ubuntu που προτείνεις.  Μπορεί να είσαι πολύ καλός τεχνικός, αλλά αλάνθαστος δεν είσαι, ούτε φυσικά είσαι και ο καλύτερος που υπάρχει. Εκεί έξω στο ιντερνετ υπάρχουν πολλές λύσεις που ίσως αποδειχτούν καλύτερες, και πρέπει να τις εξετάσεις πριν αρχίσεις να συμβουλεύεις. Γιατί η δικιά σου καλή ή η κακή σου άποψη ακούγεται περισσότερο, και επηρεάζει περισσότερους από την δικιά μου.
Η παιδεία είναι άσκηση ελευθερίας, που λυτρώνει τόσο τον μαθητή όσο και τον παιδαγωγό από μια δίδυμη υποδούλωση. Την υποδούλωση της σιωπής (που αφορά κυρίως τον μαθητή) και την υποδούλωση του μονολόγου (που αφορά κυρίως τον παιδαγωγό).

apapakL

Για το τεχνικό μέρος της συζήτησης και μόνο...

Ενα σύγχρονο και ενεργό project με clustering και advanced graphics capabilities φαίνεται να είναι αυτό:

https://www.cendio.com/



fupat2

#20
Τέλος πάντων, για να καταλήξουμε κάπου.

A) Για 3D rendering από κεντρικό server:

A1) Hardware λύση: Για βαρύ 3D rendering το export Display από τον Server σε thin clients παίζει, αν έχει ο server ειδική κάρτα Nvidia που να υποστηρίζει indirect rendering for remote applications. Στην τελική αν έχεις καλό server μπορεί να χρησιμοποιηθεί και το multiseat configuration του Χorg.

A2) Software λύση: Εναλλακτικά μια συχρονη open source software library που ξεγελά το 3D rendering των thin clients και το στέλνει στον server, φαίνεται να είναι η virtualgl, την οποία όποιος καταφέρει και την κάνει compile για LTSP, ο alkisg θα την βάλει στο πακέτο.

B) Για 3D rendering από cluster farm:

Υπάρχουν δύο είδη cluster, το multi system image και το single system image, με το πρώτο να βολεύει περισσότερο το εργαστήριό μας, αφού για μας όλα τα σχετικά καλά τερματικά του εργαστηρίου μας πρέπει αναγκαστικά να συμμετέχουν και ως πόροι και να είναι και τα ίδια μέρος του cluster. To θεωρητικό πλεονέκτημα του cluster rendering είναι ότι δεν χρειάζεται να έχουμε μια πολύ καλή και ακριβή κάρτα γραφικών σε ένα server που να εξυπηρετεί όλα τα μηχανήματα ταυτόχρονα , αλλά μπορούμε να έχουμε αρκετά μέτρια (και φτηνά) μηχανήματα τα οποία όταν δεν έχουν να κάνουν τα ίδια πολλούς υπολογισμούς, θα μπορούν να εξυπηρετούν το τερματικό που έχει ανάγκη εκείνη την στιγμή. Αυτή η υλοποίηση έχει ως bottleneck το δίκτυο, δηλαδή πρέπει οι 3D υπολογισμοί να φεύγουν στα διπλανά μηχανήματα, να εκτελούνται και να επιστρέψουν χωρίς να επηρεάζουν το frame rate.

Β1) Ηardware λύση: Ίσως να παίζει με κάρτες nvidia (π.χ. CloudLight). Δεν δουλεύει όμως στα παμπάλαια μηχανήματα που έχουμε αρκετοί απο εμάς στα εργαστήρια, αφού κατά πάσα πιθανότητα δεν θα έχουν κάρτες nvidia με δυνατότητες indirect rendering.

B2) Software: Yπάρχουν opensource software libraries που ξεγελούν το 3D rendering αδύναμων μηχανημάτων και το στέλνουν σε render clusters (π.χ. the chromium project). Δεν βρήκα όμως δωρεάν σύγχρονες libraries, για κάποιο "μυστήριο" λόγο ( 1, 2, 3 ,4, 5, 6;)) όλα αυτά τα opensource projects φαίνεται να σταμάτησαν απότομα 4-5 χρόνια πριν.  Ελπίζω κάποιος, κάποια στιγμή να βρει κάποια σύχρονη δωρεάν opensource software library που να υποστηρίζει cluster rendering. Υπο διερεύνηση είναι η ΤhinLinc που βρήκε ο apapakL, η οποία δεν είναι δωρεάν, αλλά έχει δωρεάν άδεια για μέχρι 10 μηχανήματα.


Συμπέρασμα
Αν τελικά το bottleneck του δικτύου αποτελεί το  πρόβλημά μας και άρα η χρήση ενός flat cluster δεν εξυπηρετεί, και αν δεν έχουμε και λεφτά για να αγοράσουμε μεγάλο σερβερ με καλή και ακριβή κάρτα γραφικών, μια λύση είναι να ορίσουμε δυο-τρια από τα καλύτερα μηχανήματά μας ως σερβερς, και ο κάθε σέρβερ να υλοποιεί multiseat ανά δυάδες-τριάδες εξυπηρετώντας δυό ή τρία τερματικά.
Η παιδεία είναι άσκηση ελευθερίας, που λυτρώνει τόσο τον μαθητή όσο και τον παιδαγωγό από μια δίδυμη υποδούλωση. Την υποδούλωση της σιωπής (που αφορά κυρίως τον μαθητή) και την υποδούλωση του μονολόγου (που αφορά κυρίως τον παιδαγωγό).