THMMY.gr

Έχει ασχοληθεί κανένας να ρωτήσω κάτι?

Λέει "Αν είναι μόνο 1 σήμα (Ν = 1), το παρόν δουλεύει πολύ καλά και στον υπολογιστή μου αναγνωρίζει την αλλαγή σε 1μsec".
Αν είναι όμως Ν > 1 τότε μεταβάλλει ένα σήμα κάθε φορά τυχαία και όχι όλα ταυτόχρονα και ο detector "πιάνει" τις αλλαγές μόνο του 1ου σήματος (αυτό με id 0). Αυτό θα παραμείνει έτσι ή θα χρειαστεί να φτιάξουμε Ν signal generators (SensorSignalReaders) που μου φαίνεται πιο λογικό? N detectors θα φτιάξουμε ούτως ή άλλως.

Επίσης σε ποιό σημείο χρειάζονται interrupts?? Με mutexes μόνο πιστεύω είμαστε οκ στο συγκεκριμένο πρόβλημα.

Εγω πιστευω οτι δεν χρειαζεται να φτιαξουμε Ν SensorSignalReaders, αλλα χρειαζονται N Detectors. Ποσα σηματα ομως θελει να πιανει σε 1 μs? Εμενα προσωπικα με μια προχειρη υλοποιηση με mutexes πιανει μεχρι 3 και αν παω σε 4 και πανω αρχιζει να αυξανεται ο χρονος :-\

Ναι αλλά χωρίς  Ν SensorSignalReaders μπορεί μόνο ένα σήμα να αλλάζει κάθε χρονική στιγμή που δεν ξέρω αν είναι αυτό που ζητάει. Με μια πρόχειρη υλοποίηση που λες και εμένα στα ίδια είναι και λίγα παραπάνω αν βγάλεις τα mutexes εφόσον δεν χρησιμοποιούν κοινές θέσεις μνήμης. Επίσης είπε τίποτα για την εργασία στο μάθημα αυτή την τετάρτη γιατί έλειπα?

Εγω υποθετω οτι δεν θελει να αλλαζουν δυο σηματα ταυτοχρονα επειδη λεει στην εκφωνηση
 "Eπίσης ως έχει ένα σήμα δεν αλλάζει σε λιγότερο από 1/10 το δευτερολέπτου. Τι θα γίνει αν αλλάζει πιο συχνά;"

Ισως ειναι επιθυμητο να αλλαζουν πιο γρηγορα αλλα οχι ταυτοχρονα. :-\

Δεν καταλαβαίνω κάτι τέτοιο από το παραπάνω. Απλά λέει ότι η αλλαγή πραγματοποιείται τυχαία σε χρονικό διάστημα από 1/10 sec εώς 1 sec από τη στιγμή που πραγματοποιήθηκε η προηγούμενη. Από εκεί και πέρα δεν ξέρω γιατί αυτό να μην ισχύει και για τα υπόλοιπα σήματα.

Σε ποιό σημείο του κώδικα ακριβώς συμφέρει να εφαρμόσουμε mutual exclusion; Με μια πρόχειρη υλοποίηση φτάνω στα 4 σήματα περίπου αλλά νομίζω πρέπει να είναι πιο αποδοτικός ο κώδικας....

ανεφερε κατι ο καθηγητης σχετικα με την εργασία στα τελευταία μαθήματα?

Ξέρει κάποιος τι εννοεί όταν λέει το ίδιο γρήγορα περισσότερα σήματα? Γιατι εγώ όπως το έκανα μου βγαίνουν περίπου στα 60μs κατα μέσο όρο οι χρόνοι, το οποίο μου φαίνεται αρκετά γρήγορο.

Αν το Ν είναι αρκετά μεγάλο, τότε όντως ο χρόνος είναι καλός. Απλά, μην κοιτάς τον μέσο όρο, παρατήρησε τον μέγιστο χρόνο που σου τυπώνει. Ώστε, να ξέρεις ότι όλες οι αλλαγές θα ανιχνευθούν σε χρόνο μικρότερο από αυτή τη τιμή.

Μπορεί κάποιος που έκανε την εργασία ή που έχει ασχοληθεί να μου λύσει μια απορία; Για τι τιμές του Ν μιλάμε; Γιατί όπως το σκέφτομαι εγώ βέλτιστη λύση θα έχεις όταν μπορείς να τσεκάρεις ανα πάσα στιγμή με ένα thread το κάθε σήμα που έχεις. Οπότε για να επιτύχεις αυτό που σου λέει σε 1μs να αναγνωρίζεις περισσότερα σήματα μόνο έτσι γίνεται. Βέβαια μου φαίνεται πάρα πολύ απλό για να ζητάει αυτό η εργασία αλλά δεν μπορώ να καταλάβω πως θέλει να το υλοποιήσουμε.

Θα πας και σε μεγαλύτερους αριθμούς του Ν, που θα πρέπει το κάθε νήμα να τσεκάρει πολλά σήματα και όχι ένα το καθένα (που είναι η πολύ απλή περίπτωση).

Μπορούμε δηλαδή να αναγνωρίζουμε αλλαγή περισσότερων σημάτων σε χρόνο 1μs χωρίς να έχουμε ένα thread για κάθε σήμα στην περίπτωση που έχουμε πολλούς SensorSignalReaders;   

Προφανώς ο χρόνος που θα χρειαστεί για την αναγνώριση θα είναι μεγαλύτερος, όχι 1 μs.

Δηλαδή, στην περίπτωση που έχουμε περισσότερα σήματα απο τα thread που μπορούμε να χρησιμοποιήσουμε ελέγχουμε τυχαία με όλα τα thread να δούμε ποιό σήμα άλλαξε; Επίσης έχουμε έναν SigGen και απλώς τρέχουμε πολλούς detectors πάλι τσεκάροντας τυχαία τα σήματα για κάποια αλλαγή; Ή κάποια thread αλλάζουν τα σήματα και κάποια thread τσεκάρουν;

Νομίζω ο Signal Generator που είναι υλοποιημένος στο pace.c πρέπει να μείνει ώς έχει. Αυτό που πρέπει να αλλάξουμε εμείς είναι ο changeDetector . Το πώς θα δουλεύει ο detector , είναι θέμα υλοποίησης . Προφανώς θα πρέπει να χρησιμοποιήσουμε >1 threads , αλλά από την άλλη 1 thread για κάθε σήμα είναι υπερβολικό , και δεν πιστεύω πως θα δούλευε καλα. Μπορείς να πειραματιστείς με τον αριθμό των threads , και βλέπεις. Τέλος , το να βλέπει το κάθε thread τυχαία στοιχεία του πίνακα μέχρι να ανιχνευτεί αλλαγή δεν νομίζω πως είναι πολύ καλή στρατιγική... Δεν δίνει καμία εγγύηση οτι θα ανιχνευτεί η αλλαγή σε κάποιο χρόνο , ενώ άμα σαρώνεις σειριακά όλο τον πίνακα , ή κάθε thread υποτμήματα , τότε μπορείς να βρείς ποιά είναι η χειρότερη περίπτωση at least...

Αν ισχύει αυτό ότι ο Generator μένει όπως έχει είναι πολύ μαλακία όμως, το να κάνεις πολλά threads generator και λίγα (~1) detector είναι πολύ efficient. Έστειλα μαιλ στον Σησμάνη πριν από κάτι μέρες σχετικά με αυτό αλλά δεν απάντησε...

Γενικά η εργασία είναι δύσκολη άμα δεν έχω δει καθόλου pthreads;

Όχι, τα απολύτως βασικά θέλει μόνο.

Reminder επειδή είχα ρωτήσει τον Πιτσιάνη σχετικά με αυτό:

Ο Σισμάνης δεν έχει καμία επαφή με την εργασία, οπότε για απορίες/κλπ καλύτερα κατευθείαν στον Πιτσιάνη.

Ναι ρε μάστορα , άμα ήταν να πειράζεις και τον κώδικα του signalChanger κάθε φορά που γίνεται μια αλλαγή θα μπορείς να σηκώνεις ένα flag και να αποθηκεύεις και το index σε μια global var , και τέλος , 2 γραμμές. Δεν παίζει να θέλει αυτό . Εγώ έτσι όπως το καταλαβαίνω , ο signalChanger απλά αλλάζει πράγματα σε ένα δικό του thread , και πρέπει εσύ με δικές σου συναρτήσεις να καταλαβαίνεις όσο το δυνατόν πιο γρήγορα αυτές τις αλλαγές.

Πάντς άμα στείλεις στον Πιτσιάνη και σου απαντήσει , αν μπορείς πόσταρε το και εδω μια :)

παιδιά, αν δεν έχουμε πολλους signal generators πως μπορούμε να ανιχνεύουμε πολλά σήμετα ταυτόχρονα; Σορρυ αν η ερώτηση είναι χαζή, απλά έχω μπερδευτεί πολύ.
Επίσης όταν λέμε πολλά σήματα ταυρόχρονα ποσά εννοούμε;

Δοκίμασε σε πρώτη φάση να εκκινήσεις περισσότερα νήματα που θα καλούν την ChangeDetector και άλλαξε την ChangeDetector έτσι ώστε να ελέγχει ένα κομμάτι του πίνακα signalArray. π.χ. άν βάλεις Ν=4 θα μπορούσες να έχεις στην πιο απλή περίπτωση 4 threads που το κάθε ένα θα ελέγχει και από μια θέση. Σε δεύτερη φάση κάθε thread θα μπορούσε να ελέγχει περισσότερες της μια θέσης. Εγώ έφτασα μέχρι N=600 αλλά λογικά σ' αυτό παίζει ρόλο και ο επεξεργατής, το λειτουργικό κτλ..

Όταν λες έφτασες μέχρι Ν=600 εννοείς ότι πετύχαινες χρόνους στην περιοχή του 1μs για 600 σήματα?

Ναι, worst case 0.000001 sec

Ωραιος , με τι cpu(cores/threads) εισαι?

Ο επεξεργασης είναι i-5, 2 πυρήνες, 4 λογικοί επεξεργαστές και το τρέχω στα ubuntu οπότε είναι λιγότερο επιβαρυμένο. Έβαλα 2 threads changeDetector που το καθένα είναι υπεύθυνο για 300 σήματα.

Μια ερώτηση καθώς έχω μπερδευτεί λίγο. Έστω για παράδειγμα ότι έχουμε ενα thread το οποίο ελέγχει 2 σήματα. Δεν θα υπάρχει πρόβλημα- καθυστέρηση- αν το ένα σήμα δεν αλλάξει κατάσταση από 1 σε 0 ( ουσιαστικά στο τελευταίο while) και με αυτό τον τρόπο το άλλο σήμα που ελέγχεται από το ίδιο thread περιμένει; Χρειάζεται να αλλάξουμε τον κώδικα;

Ναι πρέπει να τον αλλάξεις.

Έχουμε καμιά ιδέα τι εννοεί ο ποιητής με τον "στατιστικό χαρακτηρισμό λόγω της τυχαιότητας"; Τι περίπου πρέπει να σχολιάσουμε;

Αυτό πού το ξετρύπωσες; Εϊναι κάπου στην εκφώνηση και δεν το βλέπω;  ^eatpaper^

Απο τους βαθμους που εχουν βγει ειναι μαλλον

Έχεις δίκιο vlad!
Αυτό που καταλαβαίνω είναι ότι εκτός από τον χειρότερο χρόνο πρέπει να παρουσιάσουμε κάποια στατιστικά χαρακτηριστικά των μετρήσεων.Πιστεύω η μέση τιμή και η διακύμανση αρκούν.

Παιδια help γιατι μπορει να εχω καταλαβει το προβλημα λαθος.
Θελει να δουμε ποσα σηματα αναγνωριζονται σε 1μs ή μεχρι ποσα σηματα μπορω να αναγνωρισω αλλα το καθε ενα να αναγνωριζεται σε το πολυ 1μs;

Το 2ο καταλαβαίνω εγώ.

Και γω αυτο εκανα.Θενξ.

Χμμ, νομίζω γενικά το να εγγυηθείς χρόνο με τα Pthreads είναι περίεργο, γιαυτό ρωτάω. Έχει κανείς άλλος καμιά έμπνευση για το τι θα μπορούσε να είναι αυτός ο "στατιστικός χαρακτηρισμός";

Το οτι το μάθημα λέγεται ενσωματωμένα και βάζει εργασία η οποία θα τρέχει σε desktop σύστημα που το πατε;  :D :D

1ον. Ποιος αριθμός σημάτων θεωρείται ικανοποιητικός; Τον έχει ρωτήσει κανείς; Ας πούμε τα 1000 είναι οκ;

2ον. Όταν το τρέχω σε Ubuntu μέσω VirtualBox οι χρόνοι είναι αρκετά μεγαλύτεροι απ'όταν το τρέχω με cygwin. Λογικά είναι θέμα χαρακτηριστικών που έχω δώσει στο VM. Να συνεχίσω βάσει του cyqwin;

Βλέποντας τους βαθμούς και τα σχόλια που έχουν πάρει οι προηγούμενοι, δεν τον ενδιαφέρουν οι χρόνοι γιατί προφανώς από υπολογιστή σε υπολογιστή διαφέρει.
Φαίνεται να τον ενδιαφέρει κυρίως, τι υλοποίηση έκανες, τι εγγυύσεις μπορείς να πάρεις για αυτήν, κλπ. Να του δείξεις δηλαδή ότι έχεις νιώσει τι σημαίνει "πραγματικού χρόνου" (αυτά που λέγαμε για deadlines και worst case analysis κλπ). Τώρα, αν στο δικό σου setup αυτές τις εγγυύσεις τις παίρνεις για 100 ή 1000 σήματα, είναι δικό σου θέμα απ'όσο καταλαβαίνω...

Εάν σε μερικές μετρήσεις μου βγαίνουν αρνητικές τιμές, για παράδειγμα " 0.-00001 ", αυτό τι μπορεί να σημαίνει;

Αν το ξανά τρέξω δεν το βγάζει και φαίνεται να πιάνει τον χρόνο που ζητάει.

Υπάρχει περίπτωση πρώτα να ενεργοποιηθεί ένα σήμα, αλλά πριν προλάβει η συνάρτηση να σημειώσει πότε ενεργοποιήθηκε, το detector thread προλαβαίνει και κάνει τα δικά της πράγματα, οπότε τελικώς το TimeStamp του detection είναι ελάχιστα νωρίτερα από αυτό της αλλαγής.

Απλή λύση είναι στη συνάρτηση που ενργοποιούνται τα σήματα να σημειώνεις την χρονική στιγμή αμέσως πριν γίνει η αλλαγή, και όχι μετά.

πως το υλοποιείς; βάζεις το thread να σαρώνει σειρακά όλη την περιοχή του signalArray που του έχει ανατεθεί για να εντοπίσει πιθανή αλλαγή;

αν ναι, πως ξεπερνάμε αυτό

το πρόβλημα χωρίς να έχουμε μεγάλο delay;

Αυτη ειναι η γενικη ιδεα.

μ αυτή τη γενική ιδέα, πιάνω μέχρι περίπου 600 signals σε 1μsec (με 2 threads) - περίπου αυτό νομίζω έβγαζε κι ο Pikatchu, έχουμε ίδιο επεξεργαστή.

απλά δεν έχω νοιώσει που χρειάζεται η φάση των mutexes, στην υλοποίηση μου δεν τα βαλα πουθενά.

υγ. ως προς το ερώτημα "τι συμβαίνει αν ο SignalReader αλλάζει τιμές πιο γρήγορα από 0,1sec", απλά να τσεκάρουμε πειραματικά μέχρι που ο detector προλαβαίνει και δεν χάνει αλλαγές και να του πούμε το πρόγραμμα την παλεύει με αλλαγές με περίοδο χχ sec και πάνω;

Εγω mutex χρησιμοποιησα σε μια μεταβλητη που μετραει ποσα σηματα ανιχνευτηκαν.Οσο για το 2ο δεν ξερω,δεν εχω ασχοληθει με αυτο.

γιατί το κάνεις αυτό; εννοώ με τα printf δεν μπορείς να τσεκάρεις αν όντως εντοπίστηκαν όλα τα σήματα; μετράς κάτι άλλο που έχει σημασία;

Μπα, οχι.

Και για εδώ η εργασία έχει προθεσμία 5 Οκτωβρίου;

Ε, κατά πάσα πιθανότητα.

Θα καθεσαι να μετράς τα printf ρε μλκ; :D

Παιδιά ξέρει κανείς στα σίγουρα για πότε είναι η παράδοση;

Του έστειλα email Για τα παράλληλα αλλά πιστεύω ισχύει και για εδώ. Είπε οτι το επίσημο πρόγραμμα δείχνει τις 30 για τελευταία μέρα της εξεταστικής. Άρα μέχρι και άυριο.

του εστειλα εγω χθες για ενσωματωμενα και ειπε πως ειναι μεχρι 30 του μηνος. αν θες ομως στειλτου και εσυ για παραταση μήπως ψηθει να μας δωσει αν δει οτι ειμαστε αρκετοι....

Δεν παίζει να δώσει πάντως, να ξέρετε,

γιατί να μην δώσει? γενικά δεν είναι αυστηρός με τις προθεσμίες ο πιτσιάνης...

Για ποση ωρα τρεχετε το προγραμμα; Φανταζομαι τα 20sec που εχει βαλει default δεν του αρκουν...
Εγω έβαλα 600 sec(10 λεπτα). Φαντάζομαι αυτό αρκεί..; Καμιά γνώμη;

εισαι απλα παρανοικος.

Είχαμε μήνες για να την κάνουμε

ρε κεφτε για 1.000 σηματα π.χ. μου βγαζει αποδεκτους χρονους, αλλά σε διάστημα 10 λεπτών υπάρχουν κάποια spikes στα 0.00002 ή παραπάνω sec. άρα είναι λογικό να το τρέξεις για κανά 10λεπτο ώστε να έχεις ένα καλό δείγμα τιμών(βέβαια φταίει και ότι ζεσταίνεται το laptop μου).

Παράλληλα+εξεταστική και ορίστε που πήγε όλος αυτός ο χρόνος. 8)) Για τύπους που έκαναν ασαφή ή/και σύνθεση ενεργοπαθητικών δεν το συζητώ καν. Εγώ για πάρτι μου πρακτικά(ΜΑΛΛΟΝ) τελείωσα με ενσωματωμένα, απλά είναι κατανοητό αν υπάρχει κόσμος που δεν προλαβαίνει. Ειδικά αν έχει ακόμα εξεταστική.

1) Ναι προφανώς θέλει για μεγαλύτερο χρόνο, αλλιώς εγώ θα 'βαζα χαλαρά να τρέξει για 1 sec.
2) Εγώ μαζί σου είμαι, απλώς λέω τι θα πει αυτός

Ναι ρε, και γω να σου πω την αλήθεια δεν περιμένω να δώσει ανοιχτά παράταση. Αν και σίγουρα θα δεχτεί εργασίες με 2-3 μέρες καθυστέρηση.

Αυτό σιγουρα, αρκεί να μην το κάνουν 20 άτομα, πέρσι ήταν χαλαρός αρκετά αλλα όχι ανοιχτά όπως λες.

Άλλαξες το νόημα του προβλήματος. Τι εγγυήσεις πραγματικού χρόνου μπορεί να δώσει η λύση σου; Το ερώτημα της άσκησης είναι "Πόσα σήματα μπορεί να αναγνωρήσει μέσα σε 1μsec;" Τι ακριβώς εννοεί? Μέχρι πόσα σήματα ο χειρότερος χρόνος θα είναι 1μsec ή κάτι άλλο?

Αυτό, θέλει να του πεις ποιος είναι ο μέγιστος αριθμός σημάτων που μπορείς να ελέγχεις ώστε ο χερότερος χρόνος αναγνώρισης σε κάθε περίπτωση να είναι <= από το 1 μsec

Ty!

Καθώς και στατιστικός χαρακτηρισμός της συμπεριφοράς λογω της τυχαιότητας.
Καμιά ιδέα γαυτό?

Πέρα από τον μέγιστο χρόνο αναγνώρισης μπορείς να δείξεις και μέση τιμή, τυπική απόκλιση, ελάχιστη(?) κτλ. Απλά για να μην χαρακτηρίζει η συμπεριφορά του προγράμματος μόνο μια τιμή. Just saying.

Edit: "λόγω της τυχαιότητας" λογικά εννοεί ότι τα σήματα αλλάζουν σε τυχαίο χρόνο με τη rand(). Οπότε σε πολλές εκτελέσεις για ίδια σήματα μπορεί να έχεις διαφορετικούς μέγιστους χρόνους, αλλά οι υπόλοιπες στατιστικές τιμές δεν μεταβάλλονται τόσο

Ρε μάγκες, just asking, condition variables χρησιμοποίησε κανείς;

Μπααααα

Ρε γκάιζ... Μάθαμε τίποτα για το αν έβγαλε αποτελέσματα;; Αργήσαν λίγο, ε;;