Venus AUEB Forum

Χαιρετώ και καλό χειμώνα

Έχω την εξης απορία μπορεί ένα cluster να βοηθήσει ένα απαιτητικό game να τρέξει? Πολλοί απο εμάς έχουμε 2 και 3 pcia αντί να αναβαθμίζουμε μπορεί να βοηθήσει ένα cluster?
H ερώτηση συνίσταται στο αν το game τρέχει σαν μία η πολλές παράλληλες διεργασίες στο pc πχ 4 ταυτόχρονες συμπιέσεις αρχείων σε ένα cluster γίνονται αρκετά πιο γρήγορα απο ότι σε ένα pc .
Είναι όμως ένα game μία διεργασία ή πολλές γιατί αν είναι μία το κέρδος θα είναι ελάχιστο?

Η ερώτηση είναι άκρως φιλοσοφική αφού ούτε έχω όρεξη να βάζω windows server edition στα Pcia για να κάνω cluster ούτε μπορώ στο linux με τα open source προγραμματά του αφου απλά δεν μπορώ να παίξω games,.

Την γνώμη σας παρακαλώ

Δύσκολο, καθώς τα σημερινά games στηρίζονται πολύ στην καρτα γραφικών και όχι τόσο στη cpu.

Εσύ προφανώς εννοείς αν γίνεται ένα πρόγραμμα (στην περίπτωση μας παιχνίδι) που δημιουργεί κάποια threads να επωφεληθεί το clustering. Εδώ δεν μπορώ να σου δώσω μια σωστή απάντηση, καθώς είμαι άσχετος (ακόμα) με το θέμα...

Ναι αλλα σίγουρα ένα παιχνίδι δεν είναι μόνο γραφικά αλλίως δε θα ήθελε τόσα ΜΗz GHz το clustering σίγουρα θα βοηθήσει αν ένα παιχνίδι την ώρα που τρέχει δημιουργεί πάνω απο ένα thread αφού τα threads θα μοιράζονται στους επεξεργαστές του cluster . Ενα παιχνίδι όμως δημιουργεί πάνω απο ένα thread μία δεδομένη στιγμή ή από την αρχή έως το τέλος είναι ένα?Αυτή είναι η βασική ερώτηση

Κοίταξε να δεις σε κάθε περίπτωση μπορεί ένα distributed σύστημα να υποστηρίξει καλύτερα το παιχνίδι αλλά τα περισσότερα λειτουργικά clusters που μπορείς να στήσεις είναι SSI. Σε αυτήν την περίπτωση κάθε ξεχωριστή διεργασία και μόνο μπορεί να τρέχει παράλληλα σε ένα σύνολο απο διάσπαρτες CPUs. Στα περισσότερα παιχνίδια έχεις ένα σύνολο διεργασιών που απλά η μία εκτελείται μετά την άλλη και όχι παράλληλα. Ακόμη και να υπάρχει overlapping αυτό είναι μικρό. Δηλαδή πρόκειται για περιπτώσεις που δεν έχεις το σύνολο των διεργασιών να είναι επικαλυπτόμενες ώστε ένα clusteράκι να βοηθήσει. Τα clusters αυξάνουν σημαντικά τον χρόνο απόκρισης συστημάτων που λειτουργούν σε client-server mode και έχουν πολλές αιτήσεις για επεξεργασία ταυτόχρονα. Σε τέτοιες περιπτώσεις μία αίτηση θα εξηπηρεταίται και οι υπόλοιπες θα περιμένουν σε ένα pc με 1CPU ενώ σε ένα cluster αυτό θα γίνει σχεδόν παράλληλα(θα μοιράζονται σε όλες τις διαθέσιμες cpus οπότε τελικά στον χρόνο που χρειάζεται για να γίνει η μία επεξεργασία θα έχεις επεξεργαστεί n).

Μιλάς για διεργασίες (fork). Έστω ότι εκτελώ ένα πρόγραμμα σε ένα συστηματάκι με clusters. Ξαφνικά η διεργασία δημιουργεί ένα παιδί. Το παιδί, για να μην παλεύει με τον γονιό για την ίδια cpu (στο ίδιο μηχάνημα) θα μεταναστεύσει σε κάποιο άλλο μηχάνημα και θα εκτελείται ταυτόχρονα με τον πατέρα του;

Καλά για ξεχωριστές διεργασίες, για threads τι γίνεται όμως;

Ναι έτσι γίνεται. Εάν γίνει fork() τότε η διεργασία(παιδί) θα ξεκινήσει σε κάποιο άλλο station(ο kernel τα ρυθμίζει αυτά) ενώ το IPC είναι clisterwide και αυτό!!(κοινώς μια διεργασία με messages-queue ή PFIFO μπορεί να μιλάει με ένα παιδί που βρίσκεται σε ένα άλλο station). Όλα τα devices είναι προσβάσιμα clusterwide ενώ μπορεί να σταματίσει μιά διεργασία να εκτελείται σε μια cpu και να μεταφερθεί σε κάποια άλλη(proccess migration) και να συνεχίσει απο εκεί που είχε σταματήσει. Συνεπώς ένα prog απο πολλά threads θα τρέχει σε κάθε cpu διαφορετικό thread και τα περιεχόμενα της μήμης θα τα παίρνει απο ένα station.

Να θέσω κι εγώ άλλη μια ερώτηση, Βασίλη... Υπάρχει λειτουργικό με δυνατότητες clustering στο οποίο θα μπορούσαμε (υποθετικά) να τρέξουμε ένα (υπάρχον) παιχνίδι;

Κοίταξε υπάρχουν πολλά projects για clusters άλλα opensource άλλα όχι. Απο πλατφόρμες windows μπορείς με τα 2003 server να το κάνεις(? - δεν έχω δοκιμάσει) αυτό. Σε linux(kernel linux) περιβάλλοντα υπάρχουν τα OpenSSI projects στα οποία μπορείς να φτιάξεις cluster με linux που να έχει τέτοια υποστίριξη. Τέλος στα υπόλοιπα unixoειδή υπάρχουν αντίστοιχες κινήσεις τις οποίες λίγο(εώς καθόλου) έχω ψάξει. Οπότε εάν το παιχνίδι σου τρέχει σε πλατφόρμα Linux η λύση είναι γνωστή, απο windows βάζεις 2003 advaced server και δοκιμάζεις πάλι(αν και δεν ξέρω τι αποτελέσματα έχει εκεί γιατί το CFS - cluster fs και το process migration νομίζω είναι διαφορετικά) για τα υπόλοιπα το ψάχνουμε.

Μην ξεχνάτε ότι χρειάζεται δίκτυο πολύ μικρής καθυστέρησης (gigabit ethernet?, φτάνει το 100στάρη?) για να έχουμε ικανοποιητικά αποτελέσματα.
Βασίλη, σίγουρα γίνεται και μετανάστευση thread; Το λέω γιατί άλλο διεργασία παιδί (fork), και άλλο thread (libpthread).

Y.Γ. Το doom3 βγαίνει (σε λίγο) και για Linux. Αν έχει όρεξη κάποιος ας το δοκιμάσει και ας μας πει τη γνώμη του.

Όχι ρε τι λές σιγά μην βάλουμε και fibre. To θέμα του δικτύου που θα στηρίξει ένα cluster είναι ανάλογο του υλικού που έχεις. Εάν έχεις Pentium/Pentium-II με 66 άντε 100Mhz bus ένα 10άρι Ethernet την κάνει μια χαρά την δουλειά του. Εξάλου μεγαλύτερη καθυστέρηση θα έχεις απο το hardware/tcp/kernel παρά απο το ίδιο το φυσικό μέσο.

vagalati wrote:τανάστευση thread; Το λέω γιατί άλλο διεργασία παιδί (fork), και άλλο thread (libpthread)

Δεν το έχω δοκιμάσει για να σου πώ με 100% βεβαιότητα. Πάντος απο την στιγμή που μπορεί να κάνει migrate ένα process(+ ότι έχεις clusterwide το hardware) θα πρέπει και ένα thread να μην έχει πρόβλημα.

vagalati wrote:Μην ξεχνάτε ότι χρειάζεται δίκτυο πολύ μικρής καθυστέρησης (gigabit ethernet?, φτάνει το 100στάρη?) για να έχουμε ικανοποιητικά αποτελέσματα.

Ερώτηση: Έχει το Gigabit Ethernet μικρότερη καθυστέρηση;

Για 10Mbit ethernet:

1bit -> 100ns με διαφορική κωδικοποίηση manchester.

Για 100Mbit ethernet:

1bit -> 10ns το με κωδικοποίηση 4Β/5Β στο 100Base-TX.

Για 1000Mbit ethernet:

1bit -> 1ns με κωδικοποίηση 8B/10B στα 1000Base-SL/LX.

Τώρα σε κάθε περίπτωση έχεις delays απο το ότι:

1)Μεταφέρονται frames οπότε έχεις και bits για τα λάθη(32 - CRCs), preamble(64),mac addresses(48+48),type(16),... Δεν είναι όλα data.
2)Στο 1000άρι έχεις και ένα carrier extension που δημιουργεί λίγο παραπάνω delay(4096)bits.
3)To delay μπορεί να είναι τάξης μεγέθους παραπάνω εάν χρησιμοποιηθεί κοινό επικοινωνιακό μέσο και έχουμε συγκρούσεις(εκθετική οπισθοχώρηση), hub ή τπτ switch της πλάκας.
4)Σε κάθε περίπτωση όταν φτάσει κάτι(frame)στην κάρτα έχουμε:Interupt->"ξυπνάει" ο kernel βλέπει το interrupt και επιλέγει την διαδικασία για την επεξεργασία του frame(κατάλαβε το interypt)...μετά αναλαμβάνει το TCP/IP κλπ κλπ και τέλος έχεις τα data στην CPU.
5)Για να γλυτώσεις το hub εάν βάλεις router(ανα δύο κάρτες/workstations) τότε θα έχεις επιπλέον delay απο τις αποφάσεις routing, επαναδημιουργίες πλαισίων, πακέτων κλπ κλπ.

HdkiLLeR wrote:Όχι ρε τι λές σιγά μην βάλουμε και fibre. To θέμα του δικτύου που θα στηρίξει ένα cluster είναι ανάλογο του υλικού που έχεις. Εάν έχεις Pentium/Pentium-II με 66 άντε 100Mhz bus ένα 10άρι Ethernet την κάνει μια χαρά την δουλειά του. Εξάλου μεγαλύτερη καθυστέρηση θα έχεις απο το hardware/tcp/kernel παρά απο το ίδιο το φυσικό μέσο.

Κάτσε ρε, έστω ότι φτιάχνω ένα cluster με δύο μηχανήματα με pIII 450Mhz και 256MB@100Mhz (παίρνω ως περίπτωση τα δύο μηχανήματά μου). Η SDRAM@100 δίνουν 500-700MB/s bandwidth με πολύ λίγα nanosec καθυστέρηση. Έστω ότι τρέχω μια διεργασία και αυτή φτιάχνει μια διεργασία παιδί για να κάνει κάποιες δουλειές ταυτόχρονα (έστω μαθηματικούς υπολογισμούς πάνω σε δεδομένα που είχε ο γονιός). Η διεργασία παιδί μεταφέρεται για να τρέξει στο άλλο μηχάνημα. Το πρόβλημα που θα δημιουργηθεί είναι ότι τα δεδομένα θα υπάρχουν στη μνήμη του μηχανήματος που είναι ο γονιός και όταν θα ζητά δεδομένα για επεξεργασία το παιδί, θα γίνονται συνεχόμενα network I/O, που για 10Mbps ethernet ισοδυναμεί με disk I/O delay. Με λίγα λόγια το παιδί πιο πολύ θα περιμένει για μεταφορά δεδομένων παρά θα κάνει υπολογισμούς. Σκέψου να είχες και τίποτα p4@2Ghz...

Αυτά τα λέω με την προυπόθεση ότι το clustering σύστημα δεν κάνει τίποτα έξυπνα όπως cacheing της μιας μνήμης στο άλλο μηχάνημα ή κάτι καλύτερο ακόμα.

Ναι οκ θα περιμένει δεν το κατάλαβα όμως που είναι το πρόβλημα. θα περιμένει στην αρχή μια φορά και στην συνέχεια και ξεκινήσει κανονικά την επεξεργασία η CPU. Ο μόνος λόγος που μπορώ να φαντάστώ πως θα δημιουργούσε πρόβλημα είναι ένα σύστημα το οποίο πρέπει να αποκριθεί σε συγκεκριμένο χρονικό διάστημα. Το να έχεις λίγο delay παραπάνω στην μεταφορά και όχι στην επεξεργασία δεν ειναι και δα πρόβλημα. Στο κάτω κάτω πρέπει να γίνεται με αποδοτικό τρόπο(επικάλυψη με κάτι άλλο).

Εννοώ ότι ενώ ο γονιός μπορεί να έχει τελειώσει τη δουλειά του το παιδί θα αργήσει να τελειώσει και αυτό διότι θα περιμένει επαναλαμβανόμενα το network I/O για την μεταφορά των δεδομένων προς επεξεργασία. Επίσης θα μένει και η δεύτερη CPU ανεκμετάλευτη.
Σίγουρα πάντως αν τρέχουμε 10 διεργασίες ταυτόχρονα θα δούμε σημαντική αύξηση των επιδόσεων (μέγιστο throughput), αλλά εδώ μιλάμε για ένα game και μόνο. Εδώ η καθυστέρηση μετράει καθώς μας ενδιαφέρει να μην χάνουμε frames .

Y.Γ. Σε εμένα το unreal2003 (στο Linux) σέρνεται όχι επειδή δεν έχω καλή κάρτα γραφικών (GF4TI4200), αλλά επειδή η CPU αργεί το όλο σύστημα. Με το πέρας της εξεταστικής ίσως βάλω τα δύο συστήματα σε cluster για να δώ αν θα έχω αύξηση επιδόσεων. Θα σας πω τότε τι γίνεται πραγματικά περί.... gaming και clustering.

Σε αυτήν την περίπτωση ίσως να παρατηρηθεί αυτό που λές αλλά εν γένει η χρήση τέτοιων συστηματων γίνεται σε περιπτώσεις που έχεις τόσες πολλές αιτήσεις για επεξεργασία και δημιουργείται ουρά αναμονής. Εάν μπορούν να ξεκινήσουν η μία μετά την άλλη οι διεργασίες στο 1ο pc θα ξεκινήσουν εκεί και δεν θα μεταναστεύσει καμία. Βέβαια όλα αυτά είναι πολύ ωραία,ιδανικά και θεωρητικά. Θα το τσεκάρουμε εάν είναι !!

Στην περίπτωση του Gigabit Ethernet πρέπει να έχεις οπωσδήποτε κάποιο switch με έναν host ανά θύρα (ή router) για δίκτυο με πάνω από 2 hosts. Η επικοινωνία στο Gigabit γίνεται μόνο point to point και δεν έχεις delay από συγκρούσεις

Δεν γίνεται πάντα αυτό που λές. Στην ουσία κανένα switch δεν λειτουργεί τόσο καλά όσο λέει. Πάρε για παράδειγμα τα switches του εργαστηρίου ακόμη και απο workstation σε workstation δεν έχεις full 100Mbps ή full 10Mbps. Άντε να βγάλεις κανένα 50% της ονομαστικής ταχύτητας max(άρα πάλι υπάρχουν conflicts). Επίσης τα περισσότερα gigabit switches είναι backplate με μία θύρα για fibre(συνήθως αλλά μπορεί να είναι και απλή) και στις υπόλοιπες μπαίνουν 10/100 switches σε rack εγκαταστάσεις.

Δεν ξέρω πόσο ενδιαφέρει ακόμη αλλά κάποτε λέγαμε για cluster και gamming και είχε αναφερθεί τι θα γινότανε σε μία multithreaded εφαρμογή. Ε λοιπόν βασικά επειδή το έψαξα το θέμα δεν θα έχεις βελτίωση και είναι και λογικό γιατί το thread στην ουσία είναι μία περιοχή κώδικα με κοινά δεδομένα στα οποία απλά παίζουν σαν να λέμε δύο ροές ελέγχου.