Σελ. 1 από 5 123 ... ΤελευταίαΤελευταία
Εμφάνιση 1-15 από 73
  1. #1
    Εγγραφή
    11-07-2005
    Περιοχή
    Λουξεμβούργο
    Ηλικία
    53
    Μηνύματα
    10.348
    Downloads
    6
    Uploads
    1
    Τύπος
    FTTH
    Ταχύτητα
    500Μ Download/260M Uploa
    ISP
    Διάφοροι. Ολο
    Router
    Fritzbox!7490
    Ξεκινώ αυτό το νήμα, για να μπορούν να γίνονται συζητήσεις, σχολιασμοί αλλά και ερωτήσεις και απαντήσεις σχετικά με το QoS. Δεν είμαι κανένας network guru, και εαν κάνω κάποιο λάθος, διορθώστε με. Αλλα παρακαλώ με στοιχεία και αναφορές....

    (Παρένθεση.... Το μέλος sisifos έχει κάνει την δουλειά μετατροπής του tutorial αυτού σε μορφή pdf, ώστε να μπορείτε να το διαβάζετε και offlline, κάτι που είμαι σίγουρος ότι θέλατε πολλοί. Το link είναι αυτό )

    Εαν έχετε να πείτε κάτι, είστε ευπρόσδεκτοι.

    Στα δίκτυα υπολογιστών μεγάλο κεφάλαιο αποτελεί το πως μπορείς να διαχειριστείς καλύτερα τον πιο "στρυφνό" (δεν μπορώ να σκεφτώ καλύτερη λέξη) πόρο που έχεις, δηλαδή το φυσικό μέσο επικοινωνίας μεταξύ των υπολογιστών.
    Είτε σε περιβάλλον τοπικού δικτύου, είτε ακόμη περισσότερο σε περιβάλλον Διαδικτύου, το πρόβλημα είναι πάντα ότι η ταχύτητα διασύνδεσης είναι χαμηλότερη των δυνατοτήτων των Η/Υ και φυσικά της υπομονής μας.

    Οπότε το QoS (Quality of Service, Ποιότητα της υπηρεσίας) έρχεται να εξασφαλίσει τις προτεραιότητες που θα δίνονται σε αυτή την επικοινωνία, έτσι ώστε οι πραγματικά σπουδαίες επικοινωνίες να εξυπηρετούνται πριν τις δευτερεύουσες.

    Σε αυτό το άρθρο θα προσπαθήσουμε να διευκρινίσουμε μερικές βασικές έννοιες και να γίνει κατανοητό πως δουλεύει το διαδίκτυο με τα διάφορα πακέτα και πρωτοκολλα δεδομένων που κυκλοφορούν .....

    Το μεγαλύτερο τμήμα του άρθρου βασίζεται στο άκρως κατατοπιστικό site Practical QoS όπου έχω λάβει και σχετική άδεια από τον δημιουργό του, τον Leonardo Balliache, για την μετάφραση και δημοσίευση. Υπόψη ότι για την επαναδημοσίευση των σχετικών άρθρων θα χρειαστεί η άδεια του Leonardo.

    1. ΕΝΝΟΙΕΣ
    Σαν πρώτες έννοιες για το QoS θα πρέπει να εξετάσουμε τις εξής:

    1.1. Διαθεσιμότητα (availability)
    1.2. Χωρητικότητα κυκλώματος (bandwidth)
    1.3. Υστέρηση (latency)
    1.4. Διακύμανση καθυστέρησης (Jitter)
    1.5. Απώλειες.

    2. ΠΑΡΑΔΕΙΓΜΑΤΑ ΔΙΑΦΟΡΩΝ ΣΥΝΔΕΣΕΩΝ (ΡΟΕΣ)
    Στην συνέχεια θα δούμε πως οι διάφορετικές συνδέσεις συναγωνίζονται για δικτυακούς πόρους..

    2.1. Μια σύνδεση TCP
    2.2. Μία σύνδεση UDP
    2.3. Δύο συνδέσεις TCP
    2.4. Δύο συνδέσεις UDP
    2.5. Μία σύνδεση TCP και μια σύνδεση UDP
    2.6. Πολλές συνδέσεις TCP/UDP (over congestion) για προσομοίωση της σύνδεσης ADSL από τον πελάτη μέχρι τον ISP.

    [break=Διαθεσιμότητα]
    1.1. Διαθεσιμότητα

    Πολλοί μπορεί να πουν ότι το δίκτυα μας είναι διαθέσιμο 24 ώρες την ημέρα, 7 ημέρες την εβδομάδα, 12 μήνες τον χρόνο. Δηλαδή είναι διαθέσιμο 100 % . Αυτό είναι πολύ καλό αλλά τις περισσότερες φορές απέχει πολύ από την αλήθεια.

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

    Μια συνήθης μορφή μέτρησης της διαθεσιμότητας είναι ότι πχ για την περασμένη χρονιά, η διαθεσιμότητα του δικτύου ήταν 98 %.

    Για να δούμε τι σημαίνει αυτό: 24 ώρες Χ 365 ημέρες τον χρόνο Χ 0.02 (το ποσοστό που ήταν το δίκτυο εκτός λειτουργίας ) = 175.2 ώρες !!!

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

    Επίσης ένας άλλος παράγοντας, είναι από που βλέπουμε την διαθεσιμότητα. από την άποψη του ISP, οι 175 ώρες σε έναν χρόνο είναι διαθεσιμότητα 98 %. Όμως ο πελάτης το βλέπει λίγο διαφορετικά.

    Eάν έχουμε έναν πελάτη, επιχείρηση, με εργασιακό ωράριο 9-5, και συνολικά στο διάστημα εργασίας της επιχείρησης έχουμε τις μισές ώρες διακοπής, δηλαδή περίπου 86 ώρες τότε αυτό σημαίνει ότι από την πλευρά του πελάτη του ISP, η διαθεσιμότητα είναι : Συνολικές ώρες εργασίας σε ετήσια βάση = 8 ώρες την ημέρα Χ ( 5 ημέρες ανά εβδομάδα Χ 52 εβδομάδες - 5 ημέρες αργίας) = 2040 ώρες!!

    Άρα η διαθεσιμότητα είναι = ( 2040 συνολικές ώρες - 86 ώρες διακοπής) / (2040 συνολικές ώρες ) επί 100 = 95,7 % !!! Δηλαδή η διαθεσιμότητα για τον πελάτη του ISP, είναι μόλις 95,7% και με μόνο τις μισές ώρες διακοπής από αυτές που αναφέρεις συνολικά ο ISP.

    [break=Χωρητικότητα κυκλώματος (Bandwidth]
    1.2. Χωρητικότητα κυκλώματος (Bandwidth)
    Αυτό είναι το πιο πολυσυζητημένο θέμα και στο οποίο γίνονται και οι περισσότερες παρανοήσεις. Και αυτό γιατί βασίζεται σε μια υπόσχεση.

    Και για να το κάνουμε πιο σαφές. Ας υποθέσουμε ότι έχετε μια σύνδεση με τον ISP τύπου ADSL 512/128. Αυτό σημαίνει ότι περιμένετε να έχετε μια ταχύτητα downloading περίπου στα 52-55 KΒps.

    Έτσι κάποια ωραία μέρα, που κατεβάζετε ένα μεγάλο iso αρχείο, βλέπετε ότι ο υπολογιστής κατεβάζει με την μισή ταχύτητα ή και πολύ μικρότερη από αυτή. Άλλες φορές πάλι πιάνει τα 50 ΚΒps, άλλες φορές 40, άλλες φορές 30 και πάει λέγοντας. Που είναι λοιπόν τα 55 Κ που έπρεπε να έχετε στην ταχύτητα κατεβάσματος;

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

    Υπάρχει δηλαδή μια αλυσίδα παρόχων, από τον πάροχο του πελάτη, τον πάροχο του παρόχου που τον συνδέει με το διεθνές backbone, και από εκεί άλλοι πάροχοι, πολλοί πάροχοι στην σειρά, μέχρι τέλους στο site που θέλουμε, και με υλοποιήσεις διαφορετικών τεχνολογιών, όπως καλώδια, οπτικές ίνες, μικροκυματικά, δορυφορικά, switches, routers κλπ που όλα βάζουν το χεράκι τους στην τελική διαμόρφωση.

    Αυτή είναι η πιο απλή εξήγηση, αλλά φυσικά τα πράγματα δεν είναι πάντα τόσο απλά. Στις συνδέσεις τύπου PSTN/ISDN η ταχύτητα είναι απευθείας από τον πάροχο. Επίσης εάν έχετε μισθωμένο κύκλωμα, τότε μόνο έχετε εγγυημένη ταχύτητα ακριβώς με τον πάροχο.

    Στις περιπτώσεις ADSL, πρέπει να έχει εξηγηθεί και σε άλλα άρθρα, η σύνδεση καταλήγει σε ένα σύστημα που λέγεται DSLAM. από εκεί οδηγείται σε έναν BBRAS του ΟΤΕ που στην συνέχεια αντικρίζεται με έναν BBRAS του Παρόχου. Τώρα εάν για κάθε σύνδεση ADSL, υπήρχε ακριβώς η ταχύτητα που χρειάζεται μέχρι το BBRAS του παρόχου, θα λέγαμε ότι για την ταχύτητά μας δεν φταίει ο ΟΤΕ.

    Στην πραγματικότητα όμως, η σύνδεση από το DSLAM μέχρι το BBRAS είναι σημαντικά μικρότερη από αυτή των συνδέσεων ADSL. Μπορεί να έχουμε πχ 10 Χ 384 δηλαδή σύνολο 3840 Kbps στο DSLAM, αλλά στο BBRAS να πάει μια γραμμή ταχύτητας 1Mbps.

    Αυτό σημαίνει ότι υπάρχει μια αναλογία (το λεγόμενο contention ratio) 3840 / 1024 = 3,75 Άρα με απλά λόγια εάν και οι 10 συνδέσεις ADSL δουλεύουν στο full, θα παίρνουν 102 Kbps και όχι 384 Kbps που περιμένουν φυσικά. Αυτό γίνεται γιατί στατιστικά περιμένουν ότι δεν θα λειτουργούν όλοι την σύνδεσή τους συνεχώς, ειδικά εάν κάνουν web surfing (που να ήξεραν ότι κυκλοφορούν μουλάρια ).

    Όσο πιο μεγάλο είναι το DSLAM τόσο στατιστικά αυτό εξυπηρετεί, αλλά και πάλι παίζει και έχει να κάνει με την χρήση. Πάντως το συνηθισμένο contention ratio (αυτό που λένε δηλαδή ) είναι 50 προς 1, και για πιο μεγάλες συνδέσεις γίνεται μικρότερο (τουλάχιστον στο εξωτερικό).

    [break=Υστέρηση (latency) ]
    1.3. Υστέρηση (latency)

    Ας πούμε ένα παράδειγμα για να γίνει εύκολα κατανοητό:

    Πηγαίνετε στην τράπεζα για να κάνετε μια ανάληψη. Όλα τα ταμεία είναι άδεια από κόσμο ( θα ήθελα να το δω αυτό). Πηγαίνετε σε ένα ταμείο και κάνετε αμέσως την δουλειά σας. Το ίδιο θα συνέβαινε αρκεί και να ήταν ένα ταμείο άδειο. Τώρα πάτε μια άλλη μέρα, και υπάρχουν ουρές σε όλα τα ταμεία (τα συνηθισμένα δηλαδή ). Μπαίνετε πίσω από μια ουρά, και μετά από μισή ώρα έρχεται η σειρά σας, και κάνετε την δουλειά σας. Το παραπάνω παράδειγμα δείχνει τι σημαίνει καθυστέρηση.

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

    Συνήθως σε επίπεδο τοπικού δικτύου, ή κατευθείαν στον πάροχο, ο χρόνος είναι κάτω από 50 ms, και ουσιαστικά η καθυστέρηση αυτή δημιουργείται από την ταχύτητα μετάδοσης, το μέγεθος του πακέτου, και την ταχύτητα του εξοπλισμού στην διαμεταγωγή (switches / routers κλπ). Αυτό είναι ανάλογο του χρόνου που απαιτείται από τον ταμία της τράπεζας για να σας εξυπηρετήσει. Όταν λοιπόν αρχίσουμε να έχουμε καθυστέρηση, τότε ο χρόνος γίνεται 100, 200, 500 και μπορεί να φτάσει και ακόμη μεγαλύτερους χρόνους.

    Όταν λοιπόν συμβαίνει αυτό, τότε αρκετές εφαρμογές, και ειδικά αυτές που είναι Playback δηλαδή παίζουν ήχο ή βίντεο για παράδειγμα έχουν σοβαρό πρόβλημα. Αυτό συμβαίνει γιατί, η εφαρμογή πρέπει να "παίζει" το ίδιο - ταυτόχρονα με τον αποστολέα.

    Φανταστείτε λοιπόν μια εφαρμογή φωνής, VoIP τηλεφωνία, όπου ο αποστολέας μιλά και ο ακροατής ακούει την συνομιλία μετά από μερικά δευτερόλεπτα. Ξεκινά να μιλά ο πρώτος και ο δεύτερος ακούει κενό, τελειώνει ο πρώτος την φράση του και ο δεύτερος δεν έχει ακούσει το τέλος ακόμη, περιμένει ο πρώτος να ακούσει μια απάντηση - δεν ακούει τίποτα, επαναλαμβάνει, άλλα λέει ο δεύτερος και πάει λέγοντας. Η δυσχέρεια καθιστά άχρηστη την εφαρμογή.

    Κάτι ανάλογο συμβαίνει και με τα online παιχνίδια. εάν χρειάζεται 2 δευτερόλεπτα για να καταλάβει την κίνηση ο ένας υπολογιστής από τον άλλο, τότε πολύ απλά δεν μπορείς να παίξεις. Μια ανάλογη περίπτωση είναι το playback αρχείων βίντεο, πχ MPEG. Σε αυτή την περίπτωση υπάρχει ένα frame κλειδί, που είναι όλη η εικόνα συμπιεσμένη σαν jpeg ανάλογο, και τα υπόλοιπα καρέ στην συνέχεια είναι οι διαφορές από την πρώτη εικόνα κλειδί, μέχρι να ξαναπαρουσιαστεί εικόνα κλειδί (συνήθως κάθε 20-100 καρέ ανάλογα την πολυπλοκότητα της σκηνής). Η εικόνα κλειδί όπως καταλαβαίνετε λοιπόν είναι πολύ μεγαλύτερη σε μέγεθος από τα καρέ διαφορών, οπότε εάν δεν έρχονται με αρκετή ταχύτητα, στην εικόνα κλειδί παγώνει η εικόνα μιας και δεν προλαβαίνει να έρθει μέσα στο χρόνο του 1/25 sec (για PAL).

    Κάποιες εφαρμογές δεν επηρεάζονται από την υστέρηση. Πχ εάν κατεβάζετε κάποιο μεγάλο αρχείο από το Internet, δεν παίζει ρόλο εάν κάποια πακέτα κάνουν 100ms και κάποια άλλα 200ms να έρθουν.

    Ένα άλλο πρόβλημα που μπορεί να εμφανισθεί είναι το timeout. εάν κάποια εφαρμογή περιμένει απάντηση, και έχει προκαθορισμένο τον μέγιστο χρόνο που μπορεί να περιμένει, και αυτός ο χρόνος υπερβεί, τότε η εφαρμογή νομίζει ότι έχει χάσει την σύνδεση με το δίκτυο (δεν υπάρχει δίκτυο).

    Τα συστήματα διαμεταγωγής (πχ routers, switches κλπ), που μεταφέρουν τα πακέτων δεδομένων στο διαδίκτυο, τοποθετούν τα πακέτα αυτά σε ουρές πριν τα στείλουν. Αυτό είναι απαραίτητο για να αντιμετωπίσουν το "μπούκωμα" (congestion). Όταν λοιπόν πχ σε έναν router φτάνουν πακέτα με μεγαλύτερο ρυθμό από αυτόν που μπορεί να τα αποστείλει, τότε έχει δύο επιλογές (ο router). Να διαγράψει τα πακέτα και να χαθεί η πληροφορία ή μπορεί να προσπαθήσει να τα κρατήσει στην ουρά περιμένοντας λίγο και να τα στείλει όταν μπορέσει.

    Οι ουρές αυτές λοιπόν προκαλούν υστέρηση (latency).

    [break=Διακύμανση καθυστέρησης (Jitter)]
    1.4. Διακύμανση καθυστέρησης (Jitter)
    Όσοι διαβάζετε μέχρι τώρα (και τα βλέπετε πρώτη φορά), θα νομίζετε ότι το χειρότερο πράγμα είναι η καθυστέρηση (latency). Όμως το jitter είναι ακόμη χειρότερο.

    Ας ξαναπούμε το προηγούμενο παράδειγμα με την τράπεζα. Αν ξέρουμε (με κάποιο τρόπο), ότι η αναμονή στην ουρά είναι πάντα 20 λεπτά, τότε δεν μας κάνει και πολύ διαφορά (εκτός από τον χαμένο χρόνο μας δηλαδή), προγραμματίζουμε την επίσκεψή μας έχοντας υπόψη ότι θα περιμένουμε και 20 λεπτά στην ουρά.

    Εάν όμως η αναμονή διαφέρει και δεν μπορεί να προσδιορισθεί και μπορεί να είναι από 0 έως 2-3 ώρες, τότε τα πράγματα αλλάζουν. Δεν μπορείς να προγραμματίσεις τις δουλειές σου, και η αναμονή μπορεί να σου δημιουργήσει διάφορες ψυχικές αντιδράσεις (από ευφορία βλέποντας ταμεία άδεια, μέχρι να σπάσεις κεφάλια περιμένοντας δύο ώρες στην ουρά και να φοβάσαι να πας προς νερού σου μην χάσεις την σειρά σου...). Κάτι ανάλογο είναι και το jitter.

    Το jitter είναι η διακύμανση της καθυστέρησης. Όταν λοιπόν έχουμε σχετικά μεγάλη καθυστέρηση στα πακέτα (latency), πολλές εφαρμογές (που είναι ευαίσθητες σε αυτό) μπορούν να το πάρουν αυτό υπόψη τους και να προσαρμοστούν ανάλογα. Αλλά όταν όμως το latency διαφέρει και αλλάζει συνεχώς, τότε το πρόβλημα γίνεται πολύπλοκο και δεν μπορεί η εφαρμογή να ανταποκριθεί.

    Για παράδειγμα, ας πάρουμε μια εφαρμογή που εάν δεν πάρει απάντηση μέσα σε χ χρόνο, όπου χ = μέσος χρόνος απάντησης Χ 4 (για ασφάλεια), και έχουμε μέσο χρόνο καθυστέρησης 100 ms, και ξαφνικά η καθυστέρηση γίνεται 500 ms. Η εφαρμογή δεν ξέρει (και δεν μπορεί άλλωστε) ότι απλά η καθυστέρηση μεγάλωσε απότομα πολύ (και ίσως και για πολύ λίγο), και θεωρεί ότι δεν έχει δίκτυο (δηλαδή timeout). Έτσι λοιπόν γίνεται κατανοητό, ότι όταν έχουμε φαινόμενο jitter έχουμε ακόμη μεγαλύτερο πρόβλημα από όταν έχουμε μόνο latency.

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

    Μήπως παίζει κάτι τέτοιο στις δικές μας γραμμές με τους αυξανόμενους χρόνους στα pings μέχρι και timeouts σε πρωτόκολλα μη TCP ? Και γιατί σε πρωτόκολλα μη TCP (θα το μάθουμε αρκετά παρακάτω) ?

    [break=Απώλειες]
    5. Απώλειες

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

    Κάποια πρωτόκολλα το αντιμετωπίζουν αυτό (πχ TCP) και έτσι όταν υπάρχουν απώλειες (με απλά λόγια) ο αποδέκτης μπορεί να ζητήσει από τον αποστολέα να του ξαναστείλει τα χαμένα πακέτα και να χαμηλώσει τον ρυθμό μετάδοσης (για να μειωθεί το μπούκωμα και να μην ξαναχαθούν κι άλλα πακέτα).

    Κάποια άλλα πρωτόκολλα δεν είναι τόσο έξυπνα (ή μάλλον δεν πρέπει να είναι) όπως το TCP, για να είναι όσο το δυνατόν πιο γρήγορα (μικρότερο latency, μικρότερο overhead πακέτου κλπ) και τα χρησιμοποιούν εφαρμογές που συνήθως θέλουν συγκεκριμένο σταθερό bandwidth (cbr - constant bi rate).

    Συνήθως τέτοιες εφαρμογές είναι εφαρμογές φωνής / ήχου, και συνήθως στηρίζονται στο πρωτόκολλο UDP. Προτιμούν το UDP γιατί είναι ελαφρύ και γρήγορο, γιατί δεν θέλουν την αναμετάδοση των πακέτων (τι νόημα θα είχε άλλωστε; ) και έχει μικρό latency. Χρησιμοποιούν πάνω από το UDP το RTP για το sequencing των πακέτων (να μπαίνουν στην σειρά κατά την λήψη, γιατί μπορεί να έρθει το νο 2 πακέτο πριν το νο 1).

    Αλλά το UDP όμως έχει τα δικά του προβλήματα. Δεν ανταποκρίνεται στο μπούκωμα. Όταν αρχίσουν να διαγράφονται πακέτα λόγω congestion, δεν μπορεί να συμμορφωθεί (όπως το TCP) και να χαμηλώσει τον ρυθμό μετάδοσης. Αντίθετα διατηρεί μια σταθερή ροή πακέτων, σύμφωνα με τις απαιτήσεις της εφαρμογής, που συνεχίζουν να μπουκώνουν τους routers, και να διαγράφονται πακέτα.

    Μήπως έχουμε αρχίσει (λιγάκι) να καταλαβαίνουμε τι παίζει με το UDP ;

    [break= Μια σύνδεση TCP]
    2.1 Μια σύνδεση TCP

    Και τώρα μπαίνουμε σε πιο δύσκολα κεφάλαια.

    Τα επόμενα μηνύματα έχουν σκοπό να δείξουν την αλληλεπίδραση των συνδέσεων TCP / UDP και πόσο επηρεάζουν το QoS. Για τις δοκιμές αυτές χρησιμοποιήθηκε ένα ιδεατό δίκτυο πάνω στο οποίο έγιναν μετρήσεις, το ns-2 network simulator

    Ξεκινάμε λοιπόν την μελέτη μας με μια μόνο σύνδεση TCP, που είναι μια απλή περίπτωση, προκειμένου να δούμε και να εξοικειωθούμε με την συμπεριφορά της σε ένα αφόρτιστο δίκτυο. Έχουμε λοιπόν το παρακάτω δίκτυο με μια γραμμή 2 Mbps.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2869.gif 
Εμφανίσεις:  135 
Μέγεθος:  2,4 KB 
ID: 6349

    Και στα δύο άκρα έχουμε TCP, στο Α έχουμε ένα FTP source, που μπορεί να στείλει πακέτα τόσο γρήγορα όσο αντέχει το δίκτυο. Τα πακέτα έχουν μέγεθος 1000 bytes.

    Ο σταθμός Β, το μόνο που κάνει είναι να λαμβάνει τα πακέτα και να το γνωστοποιεί στον Α. Τα πακέτα γνωστοποίησης (ack) έχουν μέγεθος 40 bytes.

    Η γραμμή είναι 2Mbps και έχει καθυστέρηση μετάδοσης 10ms. Η buffer έχει χωρητικότητα 20 πακέτων, άρα η ουρά μπορεί να έχει μέγιστο 20 πακέτα. Χρησιμοποιείται απλή FIFO, δηλαδή ότι πακέτο μπαίνει πρώτο, βγαίνει πρώτο, όπως μια απλή ουρά. εάν γεμίσει η ουρά, και συνεχίζουν να έρχονται πακέτα (γρήγορα), και δεν έχει χώρο στην buffer (ουρά), αυτά τα πακέτα διαγράφονται. Αυτή η στρατηγική ονομάζεται droptail και είναι η συνηθέστερη στο διαδίκτυο.

    Ξεκινά λοιπόν ο σταθμός Α, να στέλνει πακέτα FTP στον Β, την χρονική στιγμή 0.1 sec. Η διαδικασία σταματά την χρονική στιγμή 10 sec.

    Θα μελετήσουμε τα εξής αποτελέσματα:
    1. Στιγμιαία ταχύτητα μεταφοράς σε Kbps
    2. Ταχύτητα μεταφοράς συστήματος σε Kbps
    3. Latency σε ms 4. Jitter σε ms
    5. Πόσα bytes μεταφέρθηκαν
    6. Απώλειες.

    Οι μετρήσεις στα γραφήματα εξομαλύνθηκαν με EWMA (Exponential Weighted Moving Average). Το πρώτο γράφημα μας δείχνει την στιγμιαία ταχύτητα μεταφοράς

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2873.png 
Εμφανίσεις:  154 
Μέγεθος:  2,9 KB 
ID: 6350

    Πάρα πολύ ωραία συμπεριφορά. Το TCP αυξάνει ομαλά (και γρήγορα) την ταχύτητά του μέχρι να φτάσει σχεδόν τα 2Mbps, μέσα σε 0.4 sec. από εκεί και πέρα χρησιμοποιεί όλη την διαθέσιμη χωρητικότητα του link μέχρι που τελειώνει. Δεν μπορεί να πιάσει όλο το διαθέσιμο εύρος, γιατί μεταφέρονται και πακέτα ACK.

    Έτσι έχουμε: 1000/1040 * 2000 kbps ~ 1923 kbps

    [break= Μια σύνδεση TCP (b)]
    2.1.β
    Δεν χρειάζεται να πούμε στο TCP, πόση είναι η διαθέσιμη χωρητικότητα του δικτύου. Προσαρμόζεται μόνο του αυτόματα και χρησιμοποιεί όσο μπορεί να πάρει.

    Η στιγμιαία ταχύτητα υπολογίζεται διαιρώντας τον αριθμό των bytes του κάθε πακέτου δια του χρόνου μέχρι να πάει το πακέτο στο προορισμό του. Η ταχύτητα συστήματος υπολογίζεται διαιρώντας το σύνολο των bytes που στάλθηκαν μέχρι την δεδομένη στιγμή, με το συνολικό χρόνο μέχρι εκείνη την στιγμή. Και αυτό είναι που έχει σημασία, γιατί μας δίνει πόσα πραγματικά bytes μεταφέρονται σε κάθε μονάδα χρόνου.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2874.png 
Εμφανίσεις:  69 
Μέγεθος:  3,2 KB 
ID: 6354

    Όπως λοιπόν φαίνεται εύκολα και από το δεύτερο διάγραμμα, η συνολική ταχύτητα μετάδοσης αυξάνεται σταδιακά μέχρι να φτάσει το όριο των σχεδόν 2 Mbps.

    Και τώρα το latency. Πόσο χρόνο χρειάζεται από την στιγμή που ξεκινήσει ένα πακέτο από τον αποστολέα (Α) να φτάσει στον αποδέκτη (Β).

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2875.png 
Εμφανίσεις:  64 
Μέγεθος:  2,9 KB 
ID: 6355

    Μόλις φτάσει στην σταθερή αποστολή με 2Mbps (στο 0.5 sec) βλέπουμε ότι το latency πιάνει μια σταθερή τιμή περίπου 72ms. Πως γίνεται αυτό; Παρακάτω θα δούμε ότι και υπολογιστικά, στο απλό αυτό σενάριο μπορούμε να υπολογίσουμε το latency με αρκετή ακρίβεια. Φυσικά ο χρόνος των 72ms δεν είναι ικανοποιητικός για εφαρμογές φωνής / εικόνας, ειδικά για μια τόσο απλή και γρήγορη σύνδεση. Παρακάτω θα δούμε την διαφορά με το UDP και γιατί προτιμείται σε σχέση με το TCP.

    Όσο για το jitter έχουμε το παρακάτω γράφημα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2876.png 
Εμφανίσεις:  61 
Μέγεθος:  2,6 KB 
ID: 6356

    Δηλαδή μια αναμενόμενη συμπεριφορά. Αφού το latency παραμένει σταθερό, το jitter είναι μηδέν από το 0.5 sec μέχρι το τέλος.

    [break= Μια σύνδεση TCP (c)]
    2.1.c

    Έχουμε λοιπόν συνολικά σταλθέντα από το Α στο Β (μας τα δίνει το σύστημα): KB sent: 2421.289062
    Κάνοντας υπολογισμούς για την συνολική ταχύτητα μετάδοσης του συστήματος έχουμε: st = 2421 KB * 8 bits / byte / 9.9 seconds = 1956 Kbps

    Ας δούμε και τις απώλειες. Υπολογίζουμε τις απώλειες διαιρώντας τα πακέτα που έχουν διαγραφεί, με το σύνολο των πακέτων που έχουν σταλεί.

    Έτσι έχουμε:
    Packets sent: 2385
    Packets dropped: 0
    Total losses: 0.000000%

    Μηδενικές απώλειες.

    Φαίνεται λοιπόν ότι το TCP είναι ένα τέλειο πρωτόκολλο. Χρησιμοποιεί το μέγιστο που μπορεί, έχει σχετικά καλό latency, μηδέν jitter, σταθερή ταχύτητα μετάδοσης και καθόλου απώλειες.

    Για να δούμε τι γίνεται εάν αλλάξουμε κάποιες παραμέτρους. Τι θα γίνει αν αλλάξουμε και αντί για πακέτα των 1000 bytes έχουμε πακέτα των 100 bytes;

    Το γράφημα της στιγμιαίας ταχύτητας μεταφοράς είναι ως εξής:

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2878.png 
Εμφανίσεις:  92 
Μέγεθος:  3,2 KB 
ID: 6357

    Όπα, εδώ κάτι συμβαίνει...

    Παρόλο που γίνεται εξομάλυνση των μικροδιαφορών για να φαίνεται το γράφημα καλύτερα, εδώ προφανώς οι διαφορές είναι πολύ μεγαλύτερες. Βλέπουμε λοιπόν μια παλινδρόμηση γύρω στα 1800Kbps. Η παλινδρόμηση πρέπει να είναι πολύ μεγάλη γιατί διαφορετικά θα εξομαλύνονταν στο γράφημα. Σίγουρα μια τέτοια συμπεριφορά θα πρέπει να επηρεάζει και την συνολική ταχύτητα μετάδοσης.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2879.png 
Εμφανίσεις:  71 
Μέγεθος:  3,4 KB 
ID: 6358

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

    Πως μπορεί να γίνει αυτό; Λοιπόν τα πακέτα έχουν πλέον μέγεθος 100 bytes και τα ACK πακέτα έχουν μέγεθος 40 bytes. Η απόδοση της μεταφοράς λοιπόν θα πρέπει να είναι πλέον μικρότερη: 100/140 * 2000 kbps ~ 1428 kbps

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

    [break= Μια σύνδεση TCP (d)]
    2.1.d
    Τι συμβαίνει όμως με το latency;

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2880.png 
Εμφανίσεις:  43 
Μέγεθος:  3,0 KB 
ID: 6359

    Όπως ίσως οι πιο πολλοί θα περιμένατε, με μικρότερα πακέτα έχουμε πλέον και μικρότερο latency, μιας και μικρότερα πακέτα περνάνε πιο γρήγορα από την γραμμή. Η γραμμή μας έχει μια καθυστέρηση 10ms (λόγω μετάδοσης του σήματος σε συγκεκριμένη απόσταση μαζί με την καθυστέρηση που δημιουργεί ο ενεργός εξοπλισμός), και βλέπουμε ότι η καθυστέρηση που έχουμε είναι βασικά η καθυστέρηση της γραμμής (10.5ms). Αφού βλέπουμε ότι η καθυστέρηση έχει μια σταθερότητα, λογικά πρέπει να περιμένουμε ότι και το jitter θα πρέπει να είναι μηδενικό.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2881.png 
Εμφανίσεις:  40 
Μέγεθος:  2,6 KB 
ID: 6360

    Ας δούμε και πόσα bytes μεταφέρθηκαν: KB sent: 1297.500000

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

    Packets sent: 9491
    Packets dropped: 0
    Total losses: 0.000000%

    Παρόλο που είχαμε σημαντική μείωση της απόδοσης, οι απώλειες παραμένουν 0%

    [break= Μια σύνδεση TCP (e)]
    2.1.e
    Είδαμε τι γίνεται με μικρά πακέτα, τώρα για να δούμε τι θα γίνει εάν μεγαλώσουμε τα πακέτα και από 1000 bytes τα κάνουμε 4000 bytes.

    Έτσι λοιπόν έχουμε για την στιγμιαία ταχύτητα το παρακάτω γράφημα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2902.png 
Εμφανίσεις:  50 
Μέγεθος:  2,9 KB 
ID: 6364

    Όπως φαίνεται και από το γράφημα, είναι κάτι παρόμοιο με την περίπτωση που είχαμε πακέτα των 1000 bytes, μόνο που παρατηρούμε μια μεγαλύτερη καθυστέρηση για να φτάσει την οριακή ταχύτητα.

    Για να δούμε και την συνολική ταχύτητα συστήματος.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2901.png 
Εμφανίσεις:  38 
Μέγεθος:  3,0 KB 
ID: 6363

    Και εδώ βλέπουμε την ίδια συμπεριφορά.

    Ας δούμε και το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2900.png 
Εμφανίσεις:  51 
Μέγεθος:  3,0 KB 
ID: 6362

    Ουπς!! Τι έγινε εδώ; Έχουμε latency που ξεπερνά τα 300 ms. Αυτό δεν είναι καθόλου καλό για εφαρμογές ευαίσθητες στο latency (ήχου / εικόνας).

    Τι γίνεται όμως με το jitter;
    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2899.png 
Εμφανίσεις:  45 
Μέγεθος:  2,7 KB 
ID: 6361

    Παρόλο που το latency ήταν μεγάλο, δεν είχε διακυμάνσεις (εκτός λίγο στην αρχή). Έτσι φυσικό είναι να έχουμε jitter μηδενικό.

    Η συνολική μεταφορά του συστήματος είναι: KB sent: 2481.640625 από ότι φαίνεται, είχαμε μια μικρή βελτίωση, συγκεκριμένα στον ίδιο χρόνο και στην ίδια γραμμή, μεταφέραμε 60.35 KB περισσότερο, δηλαδή μια βελτίωση της τάξεως του 2.4925%.

    Χρησιμοποιώντας μεγαλύτερα πακέτα, μεγαλώνει η απόδοση μεταφοράς του συστήματος.

    Τελικά για απώλειες έχουμε:

    Packets sent: 630
    Packets dropped: 0
    Total losses: 0.000000%
    Μηδενικές απώλειες...

    Συμπέρασμα: Ανεβάζοντας το μέγεθος των πακέτων, αυξάνουμε την συνολική ταχύτητα μεταφοράς, χωρίς να επηρεάζουμε τις απώλειες, αλλά επιβαρύνουμε σημαντικά το latency.

    [break= Μια σύνδεση TCP (f)]
    2.1.f
    Μέχρι τώρα είδαμε πως συμπεριφέρεται το TCP σε μια γραμμή 2Mbps με πακέτα των 100, 1000 και 4000 bytes.

    Όμως μια γραμμή 2Mbps είναι πολύ μεγάλη (για τα ελληνικά δεδομένα τουλάχιστον). Για να δούμε τι συμβαίνει εάν μειώσουμε την ταχύτητα της γραμμής στο μισό, δηλαδή στο 1Mbps. Η καθυστέρηση μεταφοράς στην γραμμή διατηρείται στα 10ms. Έχουμε πακέτα των 1000 bytes.

    Η στιγμιαία ταχύτητα διαμορφώνει το εξής γράφημα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2913.png 
Εμφανίσεις:  45 
Μέγεθος:  2,9 KB 
ID: 6365

    Όπως φαίνεται και από το γράφημα, έχουμε μια συμπεριφορά παρόμοια με την γραμμή 2Mbps. Δηλαδή το TCP προσπαθεί να αξιοποιήσει όλο το διαθέσιμο εύρος.

    Ας δούμε και την συνολική ταχύτητα μεταφοράς.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2914.png 
Εμφανίσεις:  33 
Μέγεθος:  3,1 KB 
ID: 6366

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

    Για να δούμε τώρα και το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2916.png 
Εμφανίσεις:  35 
Μέγεθος:  3,0 KB 
ID: 6367

    Λοιπόν το latency αυξάνει και από 73 που ήτανε πάει στο διπλάσιο σχεδόν, στα 155 ms. Αυτό είναι αναμενόμενο, μιας και αφού έχει μειωθεί η χωρητικότητα του καναλιού στο μισό, λογικό είναι τα πακέτα να θέλουν τον διπλάσιο χρόνο να περάσουν από το σημείο Α στο Β.

    Όμως το jitter θα είναι:

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2917.png 
Εμφανίσεις:  33 
Μέγεθος:  2,5 KB 
ID: 6368

    Όπως είναι φυσικό, μιας και το latency διατηρείται σταθερό, τότε το jitter μηδενίζεται.

    Και τα υπόλοιπα δεδομένα έχουν ως εξής.

    Αφού μειώθηκε η ταχύτητα της γραμμής στο μισό, λογικό είναι στο ίδιο διάστημα χρόνου να έχουν μεταφερθεί περίπου τα μισά δεδομένα : KB sent: 1221.835938

    Για να δούμε και τις απώλειες.

    Packets sent: 1204
    Packets dropped: 0
    Total losses: 0.000000%

    Φανταστικό! Παρόλο που μειώσαμε την ταχύτητα της γραμμής, το TCP αξιοποιεί πλήρως την γραμμή και χωρίς απώλειες. Αυτό δείχνει πόσο πολύ καλή δουλειά έχει γίνει σε αυτό το πρωτόκολλο και καλούς αλγόριθμους ώστε να έχει μια τέτοια άριστη συμπεριφορά.

    [break= Μια σύνδεση TCP (g)]
    2.1.g
    Είδαμε μέχρι τώρα πως συμπεριφέρεται το TCP με πακέτα των 100,1000 και 4000 bytes σε μια γραμμή 2Mbps, καθώς και με πακέτα 1000 bytes σε γραμμή 1Mbps.

    Τώρα θα προχωρήσουμε την ανάλυση του TCP λίγο διαφορετικά, και θα αλλάξουμε τον αριθμό των πακέτων που κρατιούνται στην buffer. Μην ξεχνάτε πως είπαμε ότι η Buffer παίζει το ρόλο να κρατά τα πακέτα μέχρι να περάσουν στην γραμμή, σαν μια ουρά, και εάν έρχονται πακέτα πιο γρήγορα από ότι μπορεί να στείλει ο router, τότε διαγράφονται πακέτα μέχρι να αδειάσει θέση στην ουρά. Είναι η τακτική drop tail.

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

    Λοιπόν είδαμε στα προηγούμενα την συμπεριφορά με buffer των 20 πακέτων. Για να δούμε πως συμπεριφέρεται αν αυξήσουμε την Buffer σε 50 πακέτα.

    Η στιγμιαία ταχύτητα είναι ακριβώς η ίδια.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2873.png 
Εμφανίσεις:  32 
Μέγεθος:  2,9 KB 
ID: 6369

    Το ίδιο συμβαίνει φυσικά και στην συνολική ταχύτητα του συστήματος.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2874.png 
Εμφανίσεις:  30 
Μέγεθος:  3,2 KB 
ID: 6370

    Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2875.png 
Εμφανίσεις:  29 
Μέγεθος:  2,9 KB 
ID: 6371

    Είναι ακριβώς το ίδιο! Τώρα κάποιοι μπορεί να αναρωτηθούν, μα καλά αφού έχουμε μεγαλώσει την ουρά, δεν πρέπει να καθυστερεί περισσότερο;

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

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2921.png 
Εμφανίσεις:  54 
Μέγεθος:  2,9 KB 
ID: 6372

    Λοιπόν τι μας λέει αυτό το γράφημα. Μας δείχνει πόση από την buffer είναι κατειλημμένη κάθε στιγμή. Είναι το ανάλογο του πόσα άτομα περιμένουν στην ουρά κάθε χρονική στιγμή στο ταμείο της τράπεζας. Αυτό που βλέπουμε εδώ, είναι ότι δεν ξεπερνά τα 14 πακέτα η ουρά. Άρα είτε 20 πακέτα διαθέτει η Buffer είτε 50 είναι το ίδιο, γι αυτό και έχουμε τα ίδια γραφήματα σε ταχύτητες και σε latency.

    Κάποιος μπορεί να αναρωτηθεί, μα πως γίνεται να μην γεμίζει η Buffer; Το πρωτόκολλο TCP ανακαλύπτει την ταχύτητα μετάδοσης (σημείο Α) και στέλνει πακέτα με την ταχύτητα που μπορεί να εξυπηρετεί η γραμμή. Έτσι διατηρείται σταθερά ίδιος ο αριθμός πακέτων στην buffer.

    [break= Μια σύνδεση TCP (h)]
    2.1.h
    Τώρα θα δούμε πως μπορούμε με απλούς υπολογισμούς να βγάλουμε κάποια συμπεράσματα.

    Ας υπολογίζουμε το latency.

    Γνωρίζουμε πρώτα από όλα ότι η γραμμή (σαν γραμμή λόγω απόστασης / εξοπλισμού κλπ) μας δημιουργεί μια καθυστέρηση 10ms. Άρα έχοντας πακέτα των 1000 bytes, μια buffer με 14.5 πακέτα κατάληψη, και μια γραμμή των 2Mbps έχουμε υπολογιζόμενο latency ουράς = ( πακέτα στην ουρά * μέγεθος πακέτου ) / ( ταχύτητα γραμμής σε bytes) = ( 14.5 * 1000 ) / ( 2 * 1024 * 1024 / 8 ) = 55.31 ms αυτά τα 55.31 ms είναι ο χρόνος που ξοδεύεται μέσα στην buffer, στην ουρά μέχρι το πακέτο, να μπει στην γραμμή (στο καλώδιο που λέμε).

    Τώρα ο χρόνος που κάνει το πακέτο να "περάσει" από μια γραμμή 2Mbps, είναι χρόνος μεταφοράς πακέτου = ( μέγεθος πακέτου / ταχύτητα γραμμής σε bytes ) = ( 1000 ) / ( 2 * 1024 * 1024 / 8 ) = 3.81 ms

    Ναι, αλλά είπαμε ότι και το καλώδιο έχει και την δική του καθυστέρηση, 10ms, οπότε τα αθροίζουμε όλα για να βγάλουμε την συνολική καθυστέρηση latency = 55.31 + 3.81 + 10 = 69.12 ms

    Φανταστικό!!! Χωρίς άλλα δεδομένα, πέραν από την κατάληψη στις Buffers, βγάλαμε το latency καθαρά με υπολογισμούς και μάλιστα πολύ κοντά σε αυτό που έβγαλαν οι μετρήσεις που ήταν 72 με 73 ms. Σε συνέχεια των προηγούμενων, η αύξηση της buffers στα 50 πακέτα αφήνει ακριβώς το ίδιο latency και φυσικά το jitter. Επίσης παραμένουν τα ίδια σε αριθμό τα πακέτα που έχουν μεταφερθεί και οι απώλειες επίσης μηδέν. Δηλαδή δεν υπάρχει καμία απολύτως διαφορά με τις πρώτες μας μετρήσεις (πακέτα των 1000 bytes) και αυτό δικαιολογείται από το γεγονός ότι υπάρχουν 14 πακέτα συνεχώς μέσα στην ουρά.

    [break= Μια σύνδεση TCP (i)]
    2.1.i
    Ξέρω γίνεται κουραστικό, αλλά μόνο έτσι μπορούμε να καταλάβουμε πως όλες αυτές οι παράμετροι επηρεάζουν την ποιότητα επικοινωνίας και της ταχύτητας.

    Τώρα θα κάνουμε κάτι άλλο. Θα μειώσουμε την buffer στα 5 πακέτα μόνο. Για να δούμε πως συμπεριφέρεται το TCP;

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2923.png 
Εμφανίσεις:  63 
Μέγεθος:  3,6 KB 
ID: 6373

    Όπα, τι γίνεται εδώ;;; Φαίνεται ότι το TCP έχει κάποιο πρόβλημα. Αρχίζει λοιπόν να έχει ενδιαφέρον. Φαίνεται λοιπόν ότι το TCP θέλει να έχει μια ουρά περίπου 14 πακέτων. Όταν λοιπόν ο router του κόβει (διαγράφει πακέτα) και θα δούμε παρακάτω εάν συμβαίνει αυτό (απώλειες), τότε το TCP κατεβάζει ταχύτητα.

    Αλλά επειδή το bandwidth της γραμμής είναι υψηλό (σε τέτοια γραμμή είναι αδικαιολόγητο να έχεις τόσο μικρή buffer), προσπαθεί να ανεβάσει και πάλι την ταχύτητα, για να πιάσει το όριο, οπότε ξαναρχίζουν τα drop tails. Και πάλι από την αρχή γι αυτό και παρουσιάζεται αυτό το γράφημα.

    Το συμπέρασμα που βγαίνει από εδώ είναι, ότι εάν έχεις μεγάλες buffers μπορεί να αυξηθεί το latency σε περίπτωση υπερφόρτωσης, αλλά εάν έχεις μικρές buffers τα πράγματα γίνονται χειρότερα για το TCP γιατί συνεχώς ανεβοκατεβαίνει.

    Για να δούμε και το γράφημα της συνολικής ταχύτητας.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2924.png 
Εμφανίσεις:  44 
Μέγεθος:  4,0 KB 
ID: 6374

    Δεν χρειάζεται να πούμε ότι η αποτελεσματικότητα της γραμμής πάει περίπατο, μειώνοντας μόνο τις buffers!!! Το μέγιστο που πιάνουμε σε ταχύτητα είναι περίπου 1700Kbps και αυτό μετά από 10 δεύτερα σχεδόν. Τώρα όμως αφού είναι λιγότερα πακέτα στην ουρά, θα πρέπει λογικά το Latency να είναι μικρότερα (μην ξεχνάτε ότι μόνο η ουρά έβαζε 53 ms latency σύμφωνα με τους προηγούμενους υπολογισμούς πιο πριν).

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2925.png 
Εμφανίσεις:  47 
Μέγεθος:  3,1 KB 
ID: 6375

    Βλέπουμε λοιπόν ότι όντως το latency μειώθηκε, αλλά παρουσιάζει σκαμπανεβάσματα. Λογικό, μιας και Έχουμε σκαμπανεβάσματα στην ροή των πακέτων. Αυτό σίγουρα θα μας κάνει και ζημιά στο jitter.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2926.png 
Εμφανίσεις:  42 
Μέγεθος:  3,0 KB 
ID: 6376

    Με μια λέξη, χάλια. Θα μπορούσε βέβαια να είναι και χειρότερα.

    Όμως παρόλο που το latency είναι χαμηλό, το γεγονός ότι έχουμε πλέον jitter, δημιουργεί προβλήματα σε εφαρμογές real time. Οπότε η μείωση των buffers μόνο κακό έκανε και καθόλου καλό ( το όφελος από το χαμηλότερο latency εξανεμίζεται από το jitter). Άρα η μείωση της buffers μας έκανε μεγάλη ζημιά.

    Για να δούμε πόσα bytes μεταφέρθηκαν. KB sent: 2088.164062

    Έχουμε χάσει κοντά 400ΚΒ, μια μείωση περίπου στα 16.6 % της συνολικής ταχύτητας.

    Για να δούμε και τις απώλειες.

    Packets sent: 2097
    Packets dropped: 40
    Total losses: 1.907487%

    Μμμμμ. Για πρώτη φορά έχουμε απώλειες. Όπως είπαμε και λίγο πιο πάνω, μια τόσο μικρή ουρά, σίγουρα "γεμίζει" με αποτέλεσμα να διαγράφονται πακέτα. Και έτσι για πρώτη φορά έχουμε σχεδόν 2% απώλειες.

    Για να δούμε καλύτερα πως γίνεται αυτό, ας δούμε λοιπόν την κατάληψη στην buffer, δηλαδή πόσα πακέτα είναι μέσα στην buffer κάθε χρονική στιγμή.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2930.png 
Εμφανίσεις:  62 
Μέγεθος:  5,0 KB 
ID: 6377

    Και αυτό δεν φαίνεται και τόσο εντάξει... Βλέπουμε ότι δεν υπάρχει μια σταθερότητα στην ουρά όπως όταν είχαμε 20 ή 50 πακέτα μέγεθος buffer. Και αυτό δημιουργεί προβλήματα στην ταχύτητα / απόδοση της γραμμής.

    [break= Μια σύνδεση TCP (j)]
    2.1.j
    Άντε λίγο ακόμα και τελειώνουμε με το TCP.

    Λοιπόν είδαμε πως συμπεριφέρεται το TCP σε διάφορες παραμέτρους, ας δούμε όμως και τι συμβαίνει εάν αυξηθεί ο χρόνος μετάδοσης της γραμμής. Όπως είπαμε, μέχρι τώρα είχαμε 10ms που είναι το συνηθισμένο σε συνδέσεις τοπικού δικτύου, ενώ σε συνδέσεις ADSL πρέπει να είναι λίγο περισσότερο. από τι επηρεάζεται αυτός ο χρόνος;

    Πρώτα από όλα από την απόσταση. Υπάρχει κάποιος χρόνος για να μεταφερθεί κάποιο σήμα, ακόμα και εάν ταξιδεύει με την ταχύτητα του φωτός. Έπειτα υπάρχουν τα ηλεκτρονικά, που στις συνηθισμένες συνδέσεις αυτά αποτελούν τον κύριο λόγο της δημιουργίας αυτής της καθυστέρησης. Στις δορυφορικές όμως συνδέσεις, η απόσταση είναι πολύ μεγάλη και εκεί δημιουργείται σημαντική καθυστέρηση και λόγω απόστασης (ένας δορυφόρος σε γεωσύγχρονη τροχιά, απέχει από την επιφάνεια της γης περίπου 42100Km, άρα το σήμα για να πάει και να έρθει θέλει συνολικά πολλαπλάσιο χρόνο από ότι με τα επίγεια καλώδια).

    Λοιπόν για να δούμε τι θα γίνει εάν ο χρόνος αυτός αντί για 10ms γίνει 100ms. Έχουμε λοιπόν το εξής γράφημα για την στιγμιαία ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2931.png 
Εμφανίσεις:  50 
Μέγεθος:  3,6 KB 
ID: 6383

    Και η μέση ταχύτητα συστήματος φυσικά θα έχει επηρεασθεί

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2936.png 
Εμφανίσεις:  40 
Μέγεθος:  4,0 KB 
ID: 6384

    Βλέπουμε λοιπόν ότι η αύξηση του χρόνου στα 100ms έχει επηρεάσει σημαντικά το TCP, το οποίο έχει αρχίσει και πάλι τις παλινδρομήσεις και έχει επηρεάσει τόσο πολύ την ταχύτητα που στα 10 δεύτερα έχουμε μόνο γύρω στα 750Kbps. Μόνο από την αύξηση του χρόνου στην γραμμή έχουμε χάσει δηλαδή κοντά στα 1300 Kbps !!! .

    Για να δούμε τι συμβαίνει με το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2937.png 
Εμφανίσεις:  34 
Μέγεθος:  3,0 KB 
ID: 6385

    Λογικά θα περιμέναμε ότι το latency θα γινόταν περίπου 160ms. Αφού πριν είχαμε 70ms περίπου, και αυξήσαμε την καθυστέρηση της γραμμής κατά 90ms, άρα 70 + 90 = 160 ms. Όμως τα πράγματα δεν είναι έτσι και φαίνεται ότι έχουμε latency περίπου 102 ms. Τι συμβαίνει λοιπόν;

    Θα δούμε το γράφημα με τα πακέτα που είναι στην ουρά.
    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2938.png 
Εμφανίσεις:  47 
Μέγεθος:  3,5 KB 
ID: 6386

    Όπως φαίνεται, πλέον δεν χρειάζεται 14 πακέτα στην ουρά, αλλά το πολύ 1 !! Γιατί συμβαίνει αυτό; Στην περίπτωση αυτή τον ρόλο της buffer το παίζει η γραμμή.

    Φανταστείτε ότι η γραμμή είναι και αυτή μια buffer στην ουσία. Άρα έχουμε στα 100ms που χρειάζεται να περάσει το σήμα από την μια μεριά στην άλλη συνολικά 26 πακέτα στην γραμμή (θυμηθείτε ότι ο χρόνος να περάσει ένα πακέτο είναι 3.81 ms). Έτσι η πραγματική buffer άλλοτε έχει ένα πακέτο, και άλλοτε όχι και παρουσιάζει αυτό το γράφημα.

    Τελευταία ας δούμε τι γίνεται με το jitter.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2939.png 
Εμφανίσεις:  40 
Μέγεθος:  2,8 KB 
ID: 6387

    Λοιπόν, όπως το περιμέναμε αφού το latency ήταν σταθερό, το jitter είναι μηδενικό για το μεγαλύτερο μέρος της μεταφοράς.

    Σύμφωνα με τις μετρήσεις, μεταφέρθηκαν συνολικά: KB sent: 924.257812 που σημαίνει με απλά λόγια ότι έχουμε χάσει το 60% περίπου από το bandwidth.

    Όσο δε για απώλειες:

    Packets sent: 911
    Packets dropped: 0
    Total losses: 0.000000%

    Μηδενικές απώλειες!

    Και εδώ τελειώνει η ανάλυση για το TCP και για μια σύνδεση.

    Όπως καταλαβαίνετε από τα παραπάνω, το TCP είναι ένα πολύ καλό πρωτόκολλο για την επικοινωνία, προσπαθεί να πιάσει το μέγιστο που μπορεί σε ταχύτητα, αλλά επηρεάζεται σημαντικά από παράγοντες όπως η καθυστέρηση της γραμμής και το μέγεθος της buffers, ενώ τα μικρά πακέτα, ενώ μπορεί να βελτιώνουν το latency ωστόσο επιβαρύνουν σημαντικά την ταχύτητα.

    [break= Μια σύνδεση UDP]
    2.2. Μία σύνδεση UDP
    Επιτέλους να αλλάξουμε κεφάλαιο. Εδώ θα δούμε αρκετά ενδιαφέροντα πράγματα, και που είναι αντικείμενο πολλών θεμάτων στο forum.

    Πρώτα από όλα θα πρέπει να πούμε τι είναι το UDP, που "δουλεύει" και γιατί το χρησιμοποιούν κάποιες εφαρμογές. Δεν θα μπούμε σε πολλές λεπτομέρειες, αυτό είναι θέμα που αναλύετε σε αμέτρητες σελίδες, για το πως είναι δομημένο το πακέτο στο κάθε πρωτόκολλο και για την διαδικασία επικοινωνίας.

    Με απλά λόγια θα πούμε ότι αντί για 24 bytes που έχει το TCP στην επικεφαλίδα του το TCP το UDP έχει μόνον 8. Αυτό σημαίνει ότι επιβαρύνει σημαντικά λιγότερο το κάθε πακέτο σε σχέση με το TCP.

    Έπειτα στο TCP στέλνονται και πακέτα γνωστοποίησης λήψης (τα ΑCK) που μπορεί να μην συμπεριλαμβάνονται στο κάθε πακέτο, αλλά συμμετέχουν στον φόρτο μιας σύνδεσης. Στο UDP δεν υπάρχουν τέτοια πράγματα. Στο UDP, αφού γίνει η σύνδεση, αρχίζει να στέλνει ο αποστολέας με έναν Χ ρυθμό πακέτα. Το πρωτόκολλο από μόνο του δεν έχει κάποιον έλεγχο ροής ή congestion όπως έχει το TCP.

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

    Φανταστείτε μια εφαρμογή επικοινωνίας VoIP. από το σημείο Α στέλνει πακέτα στο σημείο Β. Τώρα εάν είχαμε TCP, και διαγραφόταν στην διαδρομή ένα πακέτο, σύμφωνα με το TCP θα έπρεπε να ξανασταλθεί. Δηλαδή το χαμένο πακέτο θα ερχόταν μετά από Χ χρόνο. Μα όμως ήδη θα είχε γίνει decode η φωνή από τα προηγούμενα πακέτα (θυμηθείτε μιλάμε για realtime), οπότε θα ήταν άχρηστο το πακέτο.

    Μόνο και μόνο αυτή η λειτουργία που στο TCP είναι χρήσιμη, στις εφαρμογές ήχου / εικόνας είναι βραχνάς μιας και εκτός της κανονικής ροής των πακέτων θα έχουμε την επιβάρυνση των retransmissions! Επιπλέον έχοντας πιο μικρή επικεφαλίδα το UDP, μας δίνει λιγότερη επιβάρυνση, άρα μικρότερο απαιτούμενο bandwidth.

    Μετά λοιπόν αυτή την εισαγωγή ας ξεκινήσουμε την ανάλυση του UDP και στο τέλος θα βγάλουμε και μερικά συμπεράσματα.

    [break= Μια σύνδεση UDP (a)]
    2.2.a
    Για να μπορέσουμε να μελετήσουμε το UDP, έχουμε και πάλι μια γραμμή ταχύτητας 2 Mbps, από το σημείο Α στο σημείο Β. Η προσομοίωση έγινε με το ns-2 network simulator. Είναι όπως και με το TCP απλά τώρα χρησιμοποιούμε UDP όπως φαίνεται και με το παρακάτω σχήμα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2942.gif 
Εμφανίσεις:  37 
Μέγεθος:  2,5 KB 
ID: 6388

    από το σημείο Α στέλνουμε πακέτα UDP, μεγέθους 1000 bytes (για να συγκρίνουμε με το TCP), και με σταθερή ταχύτητα 1.9Mbps (η εφαρμογή δηλαδή στέλνει με αυτό τον ρυθμό τα πακέτα). Επίσης η γραμμή έχει και πάλι όπως και πριν, καθυστέρηση 10ms. Η εφαρμογή αρχίζει να στέλνει την χρονική στιγμή 0.1 sec και σταματά την χρονική στιγμή 10 sec.

    Θα μελετήσουμε:

    1. Την στιγμιαία ταχύτητα μεταφοράς
    2. Την συνολική ταχύτητα μεταφοράς
    3. Την καθυστέρηση (latency)
    4. Το jitter
    5. Το συνολικό μέγεθος που μεταφέρθηκε
    6. Τις απώλειες.

    Τα γραφήματα έχουνε εξομαλυνθεί με την EWMA με συντελεστή 0.95 για καλύτερη αναγνωσιμότητα. Έχουμε λοιπόν στο πρώτο γράφημα την στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2943.png 
Εμφανίσεις:  39 
Μέγεθος:  2,9 KB 
ID: 6389

    Βλέπουμε ότι σχεδόν ακαριαία "πιάνει" τελική και "κλειδώνει" εκεί, στα 1900 Kbps. ( Η διαφορά μεταξύ των 1900 και του γραφήματος είναι λόγω υπολογισμού στο γράφημα 1900000/1024 γιατί στην προσομοίωση το CBR στέλνει ακριβώς 1900000 bps.)

    Η συνολική ταχύτητα του συστήματος είναι

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2944.png 
Εμφανίσεις:  34 
Μέγεθος:  3,0 KB 
ID: 6390

    Και εδώ βλέπουμε ότι πιάνει το όριο.

    Το Latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2945.png 
Εμφανίσεις:  35 
Μέγεθος:  3,3 KB 
ID: 6391

    Όπως βλέπουμε είναι πολύ καλό, μόνο 14ms!! Μην μπερδεύεστε με κάποιες στιγμιαίες διακυμάνσεις που φαίνονται στο γράφημα. Είναι 14.001 ms και 13.999 ms δηλαδή είμαστε κλειδωμένοι σταθερά στα 14. εάν θυμάστε στο TCP, με την ίδια ταχύτητα μεταφοράς είχαμε 73ms εδώ μόνο 14ms.

    Αυτός είναι ένας σημαντικός λόγος που προτιμούν το UDP για εφαρμογές realtime (πχ VoIP).

    Τώρα το jitter λογικά θα περιμένουμε να είναι μηδέν.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2946.png 
Εμφανίσεις:  33 
Μέγεθος:  3,3 KB 
ID: 6392

    Τέλειο.

    Για να δούμε και τα τελικά μεγέθη.

    Σύνολο μεταφερθέντων bytes KB sent: 2296.875000
    Packets sent: 2352
    Packets dropped: 0
    Total losses: 0.000000%

    Και μηδενικές απώλειες.

    Ας συνοψίσουμε. Στέλνουμε πακέτα με ταχύτητα λίγο μικρότερη από την διαθέσιμη, και όλα πηγαίνουν μια χαρά. Με το TCP δεν νοιαζόμαστε για την ταχύτητα του δικτύου. Η αποστολή ενός πακέτου TCP γινόταν πάντα όταν ο αποδέκτης μπορούσε να το λάβει ή ο ενδιάμεσος (πχ router) να το λάβει και να το στείλει με την σειρά του.

    [break= Μια σύνδεση UDP (b)]
    2.2.β
    Καλά όλα αυτά, αλλά ας δούμε πως συμπεριφέρεται το UDP, εάν κατεβάσουμε το μέγεθος του πακέτου από 1000 bytes σε 100 bytes.

    Πρώτα από όλα, ας δούμε την στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2952.png 
Εμφανίσεις:  38 
Μέγεθος:  2,9 KB 
ID: 6393

    Αν θυμάστε καλά, όταν στο TCP κατεβάσαμε το μέγεθος πακέτου στα 100, αυτό είχε μια άμεση επίδραση στο ίδιο γράφημα, κάνοντας μια πολύ γρήγορη παλινδρόμηση γύρω εκεί στα 1800Kbps. Εδώ βλέπουμε το ίδιο γράφημα με την περίπτωση UDP/1000 byte per packet size. Aπό αυτό φαίνεται ότι παρόλο που μειώσαμε το μέγεθος του πακέτου, και πάλι γίνεται πλήρες χρήση της γραμμής.

    Ας δούμε και την συνολική ταχύτητα του συστήματος.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2953.png 
Εμφανίσεις:  36 
Μέγεθος:  3,0 KB 
ID: 6394

    Και πάλι τα ίδια. Πλήρης αξιοποίηση!!!

    Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2954.png 
Εμφανίσεις:  33 
Μέγεθος:  3,0 KB 
ID: 6395

    Φοβερό!!! Έχουμε latency μόλις 10.4 ms!!!! Μην ξεχνάτε ότι η γραμμή δημιουργεί καθυστέρηση 10ms, Άρα έχουμε μόλις 0.4ms από όλα τα υπόλοιπα!!! Δεν είναι τυχαίο λοιπόν που προτιμούν το UDP για realtime εφαρμογές.

    Ας δούμε και το jitter

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2955.png 
Εμφανίσεις:  36 
Μέγεθος:  3,2 KB 
ID: 6396

    Αναμενόμενο. Μιας και έχουμε σταθερό latency, έχουμε jitter μηδέν (για την ακρίβεια ± 0.002 ms).

    Το σύνολο που μεταφέρθηκε είναι KB sent: 2296.191406

    και από απώλειες είχαμε

    Packets sent: 23513
    Packets dropped: 0
    Total losses: 0.000000%

    Παρόλο που έχουν δεκαπλασιαστεί ο αριθμός των πακέτων, δεν είχαμε απώλειες. Και όχι μόνον αυτό. Η διαφορά με το πακέτο των 1000 bytes στην συνολική μεταφορά είναι μόλις 0,68 ΚΒ δηλαδή αμελητέα, δηλαδή δεν έχουμε καθόλου μείωση της ταχύτητας μεταφοράς, και αντιθέτως έχουμε πετύχει και πολύ καλύτερο latency!!! Ενώ στο TCP είχαμε μειώσει το latency (όχι τόσο) επιβαρύνοντας σημαντικά όμως την συνολική ταχύτητα.

    Άρα λοιπόν γίνεται κατανοητό, γιατί προτιμάται το UDP έναντι του TCP όταν πρόκειται για μικρά πακέτα.

    [break= Μια σύνδεση UDP (c)]
    2.2.c
    Λοιπόν ας δούμε τι γίνεται στην συνέχεια με πακέτα των 4000 bytes. Για να μην τα επαναλαμβάνουμε, θα έχουμε ακριβώς τα ίδια γραφήματα για την στιγμιαία ταχύτητα καθώς και για την συνολική ταχύτητα, όπως και πιο πριν. Στο latency όμως έχουμε μια μικρή διαφορά.

    Ας δούμε το γράφημα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2961.png 
Εμφανίσεις:  33 
Μέγεθος:  3,1 KB 
ID: 6397

    Όπως βλέπουμε ανέβηκε και μάλιστα σημαντικά, έφτασε τα 26 ms.

    Αυτό δικαιολογείται πολύ εύκολα. Ένα πακέτο των 4000 bytes για να περάσει από την γραμμή 2Mbps απαιτείται χρόνος περίπου 17ms, και εάν προσθέσουμε και την καθυστέρηση της γραμμής, τότε έχουμε το συνολικό latency.

    Πάντως είναι πολύ καλύτερο από τα +300ms που ήθελε το TCP με πακέτα των 4000 bytes. από το γράφημα του latency εύκολα συμπεραίνουμε ότι το jitter πρέπει να είναι μηδενικό.

    Επίσης δεν έχουμε απώλειες, και το συνολικά bytes που μεταφέρθηκαν είναι τα ίδια με τις προηγούμενες περιπτώσεις UDP. Μέχρις στιγμής φαίνεται ότι το UDP υπερτερεί σε όλα, σε σχέση με το TCP. Στην συνέχεια θα δούμε τι γίνεται αν "στριμώξουμε" λιγάκι το UDP.


    [break= Μια σύνδεση UDP (d)]
    2.2.d
    Μέχρι τώρα είδαμε μια ιδανική συμπεριφορά του UDP, αλλά κάτω από ιδανικές συνθήκες. Όπως είπαμε και στην αρχή για το UDP, αυτό στέλνει με μια ροή σταθερή, και είχαμε επιλέξει να είναι αυτή ελάχιστα μικρότερη από την συνολική ταχύτητα της σύνδεσης.

    Για να δούμε όμως τι γίνεται, εάν η ταχύτητα της σύνδεσης πέσει στο μισό, δηλαδή στο 1Mbps, Ενώ το UDP στέλνει με τον ίδιο ρυθμό πακέτα. Θα έχουμε όλες τις παραμέτρους ίδιες με την πρώτη μελέτη που κάναμε στο UDP, εκτός από την ταχύτητα της γραμμής.

    Αρχικά μελετάμε την στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2962.png 
Εμφανίσεις:  36 
Μέγεθος:  2,9 KB 
ID: 6398

    Βλέπουμε ότι γίνεται πλήρης αξιοποίηση της γραμμής. Το γράφημα είναι σχεδόν ίδιο με τα προηγούμενα.

    Ας δούμε και την συνολική ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2963.png 
Εμφανίσεις:  46 
Μέγεθος:  3,0 KB 
ID: 6399

    Και εδώ δε βλέπουμε τίποτα διαφορετικό, εκτός του ότι μειώθηκε η συνολική ταχύτητας μιας και μειώθηκε και η ταχύτητα της γραμμής.

    Ας δούμε το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2964.png 
Εμφανίσεις:  32 
Μέγεθος:  3,2 KB 
ID: 6400

    Εδώ κάτι συμβαίνει. Εκεί που είχαμε 10ms για πακέτα των 100 bytes, και μόλις 14ms για πακέτα των 1000 bytes, εδώ φτάσαμε στα 170ms. Απαράδεκτο.... Μα πως είναι δυνατόν να προέκυψε αυτό;

    Ας δούμε πρώτα τι συμβαίνει στην ουρά όταν η ταχύτητα είναι 2Mbps.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2965.png 
Εμφανίσεις:  39 
Μέγεθος:  2,9 KB 
ID: 6401

    Όπως φαίνεται, έχουμε το πολύ 1 πακέτο στην buffer, γι αυτό και το latency είναι 14ms.

    Για να δούμε όμως τι γίνεται τώρα με το 1Mbps.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2966.png 
Εμφανίσεις:  33 
Μέγεθος:  3,1 KB 
ID: 6402

    Εδώ λοιπόν φαίνεται η αιτία του κακού. Έχουμε γεμίσει 19 πακέτα στην buffer. Αυτό επί 1000 bytes το κάθε πακέτο, μας κάνει 19000 bytes, τα οποία για να περάσουν χρειάζονται 152ms. Προσθέτουμε και τα 10ms της γραμμής και έχουμε κατευθείαν το αποτέλεσμα που βλέπουμε στο γράφημα. Γιατί συμβαίνει όμως αυτό;

    Το UDP στέλνει συνεχώς πακέτα με ρυθμό 1,9 Mbps , και τώρα που έχουμε μικρότερη γραμμή, δεν μπορούν να περάσουν όλα. Αυτό σημαίνει με απλά λόγια ότι γίνονται διαγραφές πακέτων

    Όπως φαίνεται, με 170ms latency, θα έχουμε σοβαρό πρόβλημα σε εφαρμογές που χρησιμοποιούν UDP (real time συνήθως εφαρμογές). Μήπως αυτό λέει κάτι στα παράπονα που ακούμε στο φόρουμ για τα πακέτα UDP / VoIP / Skype κλπ? Και τι κάναμε; απλά μειώσαμε την δυνατότητα της γραμμής στο μισό.

    Το επόμενο βήμα είναι να δούμε πως πάει το jitter

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2967.png 
Εμφανίσεις:  34 
Μέγεθος:  3,0 KB 
ID: 6403

    Δεν έχουμε πλέον μηδενικό jitter (και αυτό δημιουργεί ακόμη μεγαλύτερο πρόβλημα στις real time εφαρμογές). Γιατί γίνεται αυτό;

    Εάν προσέξατε, το latency έχει μια παλινδρόμηση, μικρή βέβαια αλλά συνεχόμενη γι αυτό και φαίνεται στο πιο πάνω γράφημα του latency σαν μια πολύ παχιά γραμμή. Αυτό δείχνει ότι παίζει ασταμάτητα μεταξύ 165 και 170 περίπου. Ε λοιπόν αυτή η παλινδρόμηση είναι που μας δημιουργεί το jitter, και είναι 3.789ms δηλαδή όσο το διάστημα που παίζει το latency.

    Ας δούμε και τα υπόλοιπα μεγέθη.

    Ο συνολικός όγκος που μεταφέρθηκε είναι KB sent: 1227.539062

    και όσο για απώλειες:

    Packets sent: 2352
    Packets dropped: 1095
    Total losses: 46.556122%

    Όπως φαίνεται η εφαρμογή έστειλε συνολικά 2352 πακέτα, αλλά διαγράφτηκαν (drop tail αν θυμάστε) τα 1095 μιας και η γραμμή δεν μπορούσε να τα "περάσει" όλα. Αφού η αποστολή γινόταν με μεγαλύτερη ταχύτητα (1900000 bits / second) σε σχέση με την γραμμή που ήταν 1Mbps.

    [break= Μια σύνδεση UDP (e)]
    2.2.e
    Είδαμε ακριβώς πιο πριν πόσο επηρεάζεται το UDP όταν υπάρχει "μπούκωμα" στην γραμμή. Αν θυμάστε στο TCP δεν είχαμε τέτοιο πρόβλημα. Και αυτό γιατί στο TCP, περιμένει απάντηση για να στείλει νέα πακέτα οπότε δεν χάνει πακέτα, και αξιοποιεί πλήρως την γραμμή. Στο UDP όμως, από μόνο του το πρωτόκολλο, δεν έχει τέτοια δυνατότητα.

    Στο ακριβώς προηγούμενο παράδειγμα προσπαθούσε να στείλει με ρυθμό 1.9Mbps όταν η γραμμή ήταν 1Mbps και λογικό ήταν τα 0.9 Mbps (και κάτι παραπάνω) να τα παίρνει το ποτάμι. Έτσι το TCP προσαρμόζεται από μόνο του, ενώ στο UDP για να έχουμε καλύτερα αποτελέσματα θα πρέπει να υπάρχει (μέσω της εφαρμογής) κάποιος τρόπος ελέγχου ώστε να μην υπερβαίνει τις δυνατότητες της γραμμής.

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

    Και για να το κάνουμε πιο σαφές. Έστω ότι είμαστε στο σημείο Α, και θέλουμε σύνδεση με το σημείο D. Α -> Β -> C -> D Τα ενδιάμεσα στάδια είναι διάφοροι πάροχοι, που στην πραγματικότητα είναι πολλοί περισσότεροι. Τώρα ο Β δεν δέχεται μόνο από εμάς πακέτα αλλά και από μερικές χιλιάδες συνδρομητές και ο C το ίδιο (στέλνει στο συγκεκριμένο παράδειγμα).

    Άρα για να είμαστε σίγουροι ότι θα πάνε όλα καλά με τα πακέτα UDP (στην πιο απλή περίπτωση) θα πρέπει η συνολική χωρητικότητα του B προς το C να είναι ίση με την συνολική απαιτούμενη ταχύτητα από τους πελάτες του Β. Πράγμα που φυσικά δεν συμβαίνει. 'Η θα πρέπει να έχει υλοποιήσει μια πολιτική μέσα από τους routers να προωθούνται κατά προτεραιότητα τα πακέτα UDP (με βάση κάποιους κανόνες).

    [break= Μια σύνδεση UDP (f)]
    2.2.f

    Ωραία μέχρι εδώ και έχει αρχίσει να έχει ενδιαφέρον, μιας και αρχίζουμε να καταλαβαίνουμε τι παίζεται με το UDP.

    Ας κάνουμε λοιπόν μια άλλη δοκιμή, τώρα αντί να αλλάξουμε την ταχύτητα της γραμμής, να αλλάξουμε τον αριθμό των πακέτων που έχει η buffer και από 20 να τα κάνουμε 50.Αν θυμάστε, στο TCP αυτό δεν είχε καμία επίδραση, και είχαμε ακριβώς τα ίδια αποτελέσματα.

    Για να μην κάνουμε κουραστικό το κείμενο, έχουμε ακριβώς τα ίδια αποτελέσματα. Δηλαδή η αύξηση της ουράς από 20 σε 50 πακέτα, δεν έχει καμία μα καμία διαφορά στα αποτελέσματα.

    Έχουμε ακριβώς τα ίδια όπως και στο πρώτο παράδειγμα με τα 20 πακέτα buffer.

    [break= Μια σύνδεση UDP (g)]
    2.2.g
    Ας δούμε τώρα τι γίνεται αν δυσκολέψουμε λίγο την κατάσταση. Αντί για 20 πακέτα buffer, τα κάνουμε μόνο 5 και αφήνουμε όλες τις υπόλοιπες παραμέτρους όπως το 2.2.α. Στο TCP όταν το κάναμε αυτό, είχαμε σοβαρό πρόβλημα. Εδώ τι γίνεται;

    Ας δούμε το γράφημα της στιγμιαίας ταχύτητας.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2943.png 
Εμφανίσεις:  32 
Μέγεθος:  2,9 KB 
ID: 6404

    Είναι ίδιο με αυτό στην πρώτη δοκιμή του UDP!

    Φυσικά και η συνολική ταχύτητα θα πρέπει να είναι όμοια

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2944.png 
Εμφανίσεις:  30 
Μέγεθος:  3,0 KB 
ID: 6405

    Ακριβώς! Και για να μην μακρηγορούμε, και το latency είναι το ίδιο, στα 14ms ακριβώς και φυσικά το jitter 0. Πως γίνεται αυτό;

    Λίγο πιο πριν δείξαμε σε ένα γράφημα την κατάληψη στην ουρά. Ας το ξαναδούμε.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2965.png 
Εμφανίσεις:  34 
Μέγεθος:  2,9 KB 
ID: 6406

    Τι βλέπουμε εδώ; Η buffer έχει το πολύ ένα πακέτο. Άρα είτε 5 είτε 20 είτε 50 δεν επηρεάζεται η ταχύτητα και η ποιότητα (από αυτόν τον παράγοντα) της επικοινωνίας με UDP. Ενώ αντίθετα στο TCP, μειώνοντας σε 5 πακέτα την ουρά, είχαμε δραματική πτώση της ποιότητας της επικοινωνίας τόσο σε συνολική ταχύτητα όσο και σε latency.

    Άρα το UDP επηρεάζεται λιγότερο (έως καθόλου) από το μέγεθος της buffer ενώ επηρεάζεται σημαντικά σε περίπτωση congestion.

    Έτσι βγαίνουν αυτομάτως και τα πρώτα συμπεράσματα των συνηθισμένων προβλημάτων στις ευρυζωνικές συνδέσεις του τύπου, δεν έχω πρόβλημα στο web surfing / ftp και άλλα tcp based, και έχω πρόβλημα στο VoIP, στα online παιχνίδια και λοιπά. Το TCP προσαρμόζεται, και παίζει σε περιπτώσεις congestion, το UDP όμως είναι πολύ ευαίσθητο και "κολλάει".

    [break= Μια σύνδεση UDP (h)]
    2.2.h
    Σαν τελευταία δοκιμή, ας δούμε τι συμβαίνει εάν αυξηθεί η καθυστέρηση της γραμμής από 10ms σε 100ms. Και σε αυτή την περίπτωση το TCP προβληματίστηκε αρκετά.

    Έχουμε λοιπόν

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2970.png 
Εμφανίσεις:  30 
Μέγεθος:  3,0 KB 
ID: 6407

    Βλέπουμε ότι πιάνει την ίδια "τελική" αλλά ελάχιστα πιο αργά από πριν.

    Ας δούμε και την συνολική ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2971.png 
Εμφανίσεις:  42 
Μέγεθος:  3,3 KB 
ID: 6408

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

    Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2972.png 
Εμφανίσεις:  35 
Μέγεθος:  3,0 KB 
ID: 6409

    Είναι φυσικό να είναι τόσο πολύ. Για την ακρίβεια είναι ακριβώς 90 ms επιπλέον, μιας και τόσο μεγαλώσαμε (από 10 σε 100) την καθυστέρηση της γραμμής.

    Και μιας και το latency βλέπουμε ότι παραμένει σταθερό το jitter θα είναι

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2973.png 
Εμφανίσεις:  34 
Μέγεθος:  3,2 KB 
ID: 6410

    Μηδέν.

    Ας δούμε και τα υπόλοιπα μεγέθη όπως ο όγκος δεδομένων που μεταφέρθηκε και τις απώλειες:

    KB sent: 2296.875000
    Packets sent: 2352
    Packets dropped: 0
    Total losses: 0.000000%

    Λοιπόν, φαίνεται ότι η αύξηση της καθυστέρησης δεν δημιουργεί προβλήματα στο UDP, και το μόνο που αυξάνεται είναι το latency και εκείνο μόνο τόσο όσο είναι η αύξηση της καθυστέρησης στην γραμμή (επίσης δημιουργεί και μια μικρή καθυστέρηση μέχρι να φτάσει την μέγιστη ταχύτητα αλλά αυτό είναι πολύ μικρό μέγεθος).

    [break= Μια σύνδεση UDP (i)]
    2.2.i
    Συμπεράσματα έως τώρα. Αν συγκρίνουμε το UDP με το TCP, φαίνεται ότι το UDP υπερτερεί σαφώς έναντι του TCP σε όλα τα ποιοτικά μεγέθη. Σε όλες τις περιπτώσεις που μεταβάλαμε τις παραμέτρους επικοινωνίας, εκτός από μία περίπτωση, το UDP δεν καταλάβαινε τίποτα και πήγαινε πολύ καλά.

    Σε μία μόνο περίπτωση τα πράγματα αλλάζουν όμως. Όταν η γραμμή είναι μπουκωμένη, τότε το UDP δεν τα πάει τόσο καλά ενώ αντίθετα το TCP εκεί δεν αντιμετωπίζει πρόβλημα. Αν λοιπόν υπήρχε κάποιος τρόπος να μπορεί αυτό να εξασφαλισθεί και να έχει το bandwidth που χρειάζεται ανά πάσα στιγμή, σε όλα τα στάδια μιας σύνδεσης, τότε θα είχαμε το ιδανικό πρωτόκολλο (κάτι τέτοιο μελετάται, είναι το rudp, reliable udp).

    Έτσι σε εσωτερικά δίκτυα εταιριών, που υπάρχει έλεγχος και δυνατότητα διαμόρφωσης της συμπεριφοράς επικοινωνίας με απομακρυσμένα σημεία (όχι με internet) μπορεί να παίζει πολύ καλά, και γι αυτό βλέπουμε υλοποιήσεις πχ VoIP.

    Μέχρι τώρα είδαμε την συμπεριφορά, μιας μόνο σύνδεσης. Όμως στην πράξη δεν συμβαίνει αυτό. Στην συνέχεια θα δούμε τι συμβαίνει όταν έχουμε στην ίδια γραμμή δύο TCP συνδέσεις που "συναγωνίζονται" για τον ίδιο πόρο.

    [break= Δύο συνδέσεις TCP]
    2.3 Δύο συνδέσεις TCP
    Συνεχίζουμε τα πειράματα συμπεριφοράς του δικτύου, αλλά αυτή την φορά θα ξεκινήσουμε ταυτόχρονα δύο συνδέσεις TCP. Όλα τα υπόλοιπα είναι τα γνωστά. Η γραμμή είναι 2 Mbps, με καθυστέρηση 10ms, η ουρά χωρά 20 πακέτα, η μετάδοση ξεκινά στο 0.1 δεύτερα και σταματά στα 10 δεύτερα. Το κάθε πακέτο έχει μέγεθος 1000 bytes. Στην buffer ακολουθείται η στρατηγική drop tail σε περίπτωση υπέρβασης.

    Έχουμε παρακάτω το γράφημα της σύνδεσης.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2869.gif 
Εμφανίσεις:  31 
Μέγεθος:  2,4 KB 
ID: 6411

    Ας δούμε λοιπόν τι συμβαίνει στην στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2977.png 
Εμφανίσεις:  52 
Μέγεθος:  5,4 KB 
ID: 6412

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

    Πριν η σύνδεση ήταν μόνη της και έπαιρνε όλους τους διαθέσιμους πόρους. Τώρα πρέπει να αγωνιστεί. Με το ξεκίνημα, και οι δύο συνδέσεις ανεβαίνουν όσο υπάρχει δυνατότητα, μέχρι που φτάνουν στο τέλος του διαθέσιμου bandwidth.

    Αρχίζει και λειτουργεί η διαδικασία αποφυγής υπερπλήρωσης (congestion avoidance algorithm). Έτσι και οι δύο συνδέσεις ουσιαστικά ελέγχονται από αυτόν τον αλγόριθμο και γι αυτό παρουσιάζεται αυτό το πριονωτό γράφημα. Και φυσικά αυτό επηρεάζει και την συνολική ταχύτητα (απόδοση) της γραμμής. Θα πρέπει εδώ να τονίσουμε ότι αυτή η "πριονωτή" συμπεριφορά είναι χαρακτηριστικό του TCP - Reno. Στο TCP - Vegas χρησιμοποιείται ακόμη πιο έξυπνος αλγόριθμος για να γίνεται ακόμη καλύτερη αξιοποίηση της διαθέσιμης χωρητικότητας. Αυτό όμως εφόσον όλες οι συνδέσεις είναι TCP-Vegas, γιατί πχ το TCP-Reno έχει πιο επιθετικό αλγόριθμο, και όταν υπάρχουν και TCP-Reno και TCP-Vegas, το δεύτερο υστερεί έναντι του πρώτου.

    Εδώ βλέπουμε πως η επηρεάζεται η συνολική ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2978.png 
Εμφανίσεις:  43 
Μέγεθος:  4,9 KB 
ID: 6413

    Μόλις λοιπόν τερματίσουν οι δύο συνδέσεις, και πέσουν αυτόματα χαμηλά, βλέπουμε και την συνολική πτώση στην ταχύτητα των συνδέσεων αυτών. Στην συνέχεια, όταν αναλαμβάνει ο αλγόριθμος, ανεβαίνει η ταχύτητα λίγο-λίγο προκειμένου να μην δημιουργηθεί μπούκωμα. Βέβαια αυτό το λίγο - λίγο σημαίνει ότι δεν αξιοποιούμε την γραμμή, στην αρχή, και θέλει λίγο χρόνο, μέχρι να εξισορροπηθεί η κατάσταση. Εδώ στο γράφημα φαίνεται σαν να χάνουμε πολύ, αλλά εάν η μεταφορά ήταν για μεγαλύτερο διάστημα πχ για 60 δεύτερα και όχι 10 δεύτερα θα είχαμε το παρακάτω γράφημα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2979.png 
Εμφανίσεις:  33 
Μέγεθος:  3,9 KB 
ID: 6414

    Σαν να φαίνεται καλύτερο.

    Όντως, στα πρώτα δεύτερα ζορίζεται το TCP να βρει μια ισορροπία, αλλά την βρίσκει σχετικά σύντομα, και από εκεί και πέρα συνεχίζει ακάθεκτο. Αν δε προσθέσετε όπως φαίνεται και στο γράφημα, την ταχύτητα στις δύο συνδέσεις, φαίνεται ότι είμαστε αν όχι το ίδιο τότε πολύ κοντά στο όριο της ταχύτητας της γραμμής. Θα δούμε παρακάτω με το τι όγκος μεταφέρθηκε.

    Τι γίνεται όμως με το latency;

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2980.png 
Εμφανίσεις:  32 
Μέγεθος:  3,8 KB 
ID: 6415

    Λοιπόν κατά πρώτο, φαίνεται ότι το latency είναι το ίδιο και για τις δύο συνδέσεις. Οι κόκκινες τελίτσες είναι η μια σύνδεση και η πράσινη γραμμή η άλλη. Όπως βλέπουμε παίζει στα 100ms περίπου.

    Για να δούμε και το jitter

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2981.png 
Εμφανίσεις:  32 
Μέγεθος:  3,7 KB 
ID: 6416

    Όπως φαίνεται είναι κοντά στο μηδέν.

    Στα υπόλοιπα μεγέθη έχουμε:
    Σύνδεση 1 => KB sent: 1109.101562
    Σύνδεση 2 => KB sent: 1069.492188
    Σύνολο ===> KB sent: 2178.593750

    Όταν είχαμε μια σύνδεση, είχαμε μεταφέρει 2421.29 KB περίπου, άρα έχουμε μια μείωση περίπου 10%.

    Για να δούμε και τις απώλειες:

    Για την σύνδεση 1 έχουμε:
    Packets sent: 1108
    Packets dropped: 15
    Total losses: 1.353791%

    Για την σύνδεση 2 έχουμε:
    Packets sent: 1074
    Packets dropped: 20
    Τotal losses: 1.862197%

    Έχουμε λοιπόν κάποιες απώλειες, και αυτό στον αρχικό συναγωνισμό των δύο συνδέσεων μέχρι να κατεβάσουν την ταχύτητά τους και να την ανεβάσουν λίγο-λίγο προκειμένου να εξισορροπήσουν. Έχουν σταλεί συνολικά 2182 πακέτα και είχαμε 35 πακέτα απώλειες. Άρα η συνολική απώλεια κυμαίνεται στο 1.6%

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

    [break= Δύο συνδέσεις TCP (b)]
    2.3.b
    Συνεχίζουμε την ανάλυση, κρατώντας όλες τις παραμέτρους ίδιες και αλλάζοντας το μέγεθος του πακέτου από 1000 bytes σε 100 bytes.

    Ας δούμε πρώτα την στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2998.png 
Εμφανίσεις:  33 
Μέγεθος:  3,3 KB 
ID: 6417

    Μην μπερδεύεστε που βλέπετε κυρίως πράσινο χρώμα (δηλαδή της μιας σύνδεσης). Αυτό συμβαίνει για στο γράφημα, πρώτα "βάφει" με το ένα χρώμα και μετά με το άλλο και εάν συμπίπτουν, το δεύτερο υπερκαλύπτει το πρώτο. Πάντως μερικές κουκίδες από το κόκκινο χρώμα της πρώτης σύνδεσης γλίτωσαν το βάψιμο και φαίνονται στο γράφημα.

    Τι γίνεται λοιπόν εδώ; Έχουμε και πάλι παλινδρομήσεις της ταχύτητας μόνο που έγιναν πιο έντονες και πολύ περισσότερες από πριν, γι αυτό και δεν εξομαλύνονται. Παρατηρούμε όμως ότι συμπεριφέρεται καλύτερα στο ξεκίνημα, χωρίς εκείνη την χαρακτηριστική κοιλιά που έκανε στο προηγούμενο παράδειγμα, και αυτό γιατί τα πακέτα είναι μικρότερα, άρα είχε λιγότερο (σε bandwidth) απώλεια με τον ίδιο ή και μεγαλύτερο αριθμό πακέτων (θα δούμε παρακάτω στις απώλειες).

    Η συνολική ταχύτητα διαμορφώνεται ως εξής:

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  2999.png 
Εμφανίσεις:  41 
Μέγεθος:  3,7 KB 
ID: 6418

    εάν θυμάστε από την περίπτωση μιας μόνο σύνδεσης TCP και με μέγεθος πακέτου 100 bytes, είχαμε συνολική ταχύτητα σχεδόν την μισή, δηλαδή περίπου στα 1100 Kbps. Το ίδιο βλέπουμε και εδώ, αλλά και για τις δύο συνδέσεις!!! Έτσι οι δύο συνδέσεις μαζί μας φτάνουν στην συνολική ταχύτητα σχεδόν που μπορεί να φτάσει η γραμμή μας.

    Ας δούμε και το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3000.png 
Εμφανίσεις:  41 
Μέγεθος:  3,1 KB 
ID: 6419

    Όπως και στην περίπτωση με μία σύνδεση, εκεί είχαμε 10.5ms εδώ έχουμε 12.2 ms (επειδή είναι και οι δύο συνδέσεις). Δηλαδή βασικά έχουμε την καθυστέρηση της γραμμής. Και φυσικά αυτό οφείλεται στο γεγονός ότι έχουμε μικρότερα πακέτα.

    Φυσικά σύμφωνα με το γράφημα του latency μπορούμε να καταλάβουμε πως θα είναι και το jitter.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3001.png 
Εμφανίσεις:  35 
Μέγεθος:  2,9 KB 
ID: 6420

    Ακριβώς!. Μηδέν.

    Ας δούμε και τα συνολικά μεγέθη, πόσος όγκος διακινήθηκε:

    Σύνδεση 1: KB sent: 1201.523438
    Σύνδεση 2: KB sent: 1199.062500
    Συνολικά: KB sent: 2400.585938

    από ότι φαίνεται γίνεται μια δίκαιη μοιρασιά μεταξύ των δύο συνδέσεων, και αυτό το εξασφαλίζουν αυτόματα οι αλγόριθμοι του TCP. Ίσως φανεί περίεργο, αλλά έχουμε μεγαλύτερο όγκο που διακινείται από την περίπτωση των 1000 bytes (για τις δύο συνδέσεις). Αυτό συμβαίνει γιατί πιο γρήγορα (λόγω μικρότερων πακέτων) προσαρμόζεται το TCP και μοιράζονται οι δύο συνδέσεις το διαθέσιμο bandwidth.

    Επίσης βλέπουμε και κάτι άλλο. εάν θυμάστε, όταν είχαμε μια σύνδεση με πακέτων των 100 bytes, είχαμε μια μείωση της συνολικής ταχύτητας μεταφοράς σχεδόν στο μισό. Εδώ αυτό το μειονέκτημα εξαλείφεται. Δηλαδή όταν έχουμε ταυτόχρονες πολλές συνδέσεις, έχουμε καλύτερα αποτελέσματα με μικρά πακέτα.

    Ας δούμε και τις απώλειες:

    Σύνδεση 1:
    Packets sent: 8789
    Packets dropped: 0
    Total losses: 0.000000%

    Σύνδεση 2:
    Packets sent: 8771
    Packets dropped: 0
    Total losses: 0.000000%

    Μειώνοντας το μέγεθος των πακέτων, μειώθηκε (για την ακρίβεια χάθηκε εντελώς), η αρχική κοιλιά που έκανε το TCP και το οποίο προέκυψε από απώλειες πακέτων.

    [break= Δύο συνδέσεις TCP (c)]
    2.3.c
    Σαν επόμενη δοκιμή, ας ανεβάσουμε το μέγεθος του πακέτου στα 4000 bytes. Για να δούμε πως θα πάνε οι δύο συνδέσεις όταν όλες οι υπόλοιπες παράμετροι παραμένουν όπως στην αρχή.

    Έχουμε λοιπόν στην στιγμιαία ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3002.png 
Εμφανίσεις:  34 
Μέγεθος:  5,8 KB 
ID: 6421

    Τώρα βλέπουμε μεγαλύτερες "κοιλιές" και μάλιστα επαναλαμβάνεται μικρότερη στα 5.5 δεύτερα και στα 8 δεύτερα. Επειδή χρησιμοποιούμε εξομάλυνση στο γράφημα, η "κοιλιά" στο 1 δεύτερο για την ακρίβεια "πιάνει πάτο".

    Ας δούμε και την συνολική ταχύτητα συστήματος.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3003.png 
Εμφανίσεις:  36 
Μέγεθος:  5,4 KB 
ID: 6422

    Εδώ φαίνεται πιο καλά το πρόβλημα. Μόλις προέκυψε το πρόβλημα του congestion, το TCP αντέδρασε κατεβάζοντας την ταχύτητα, και επειδή έχει πακέτα των 4000 bytes η πτώση ήταν πολύ μεγάλη. Αυτή η κοιλιά θα επηρεάσει την συνολική απόδοση σημαντικά για μικρές συνδέσεις διάρκειας μόνο 10 δευτερολέπτων (εάν η συνολική διάρκεια των συνδέσεων είναι ώρες, τότε στο σύνολο θα έχει μικρή επιρροή).

    Ας δούμε όμως και το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3004.png 
Εμφανίσεις:  36 
Μέγεθος:  4,1 KB 
ID: 6423

    Όπως βλέπουμε οι μειώσεις της ταχύτητας (με μείωση των αποστολών πακέτων) έχουν άμεσο αντίκτυπο και στο latency, και μάλιστα ακολουθούν την διακύμανση της ταχύτητας, έχοντας μια μη-σταθερή συμπεριφορά.

    Αυτό σίγουρα θα μας κάνει να έχουμε και jitter.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3005.png 
Εμφανίσεις:  31 
Μέγεθος:  3,9 KB 
ID: 6424

    Πράγματι, στην πρώτη κοιλιά (στο 1ο δευτερόλεπτο) βλέπουμε ότι και το jitter εκεί έχει μη-μηδενικές τιμές. Στην υπόλοιπη διάρκεια είναι κοντά στο μηδέν (αλλά όχι απόλυτα). Σε αντιδιαστολή, όταν είχαμε μια σύνδεση με πακέτα TCP των 4000 bytes, είχαμε μεν latency 320ms αλλά σταθερό και jitter μηδέν.

    Ας δούμε και τα υπόλοιπα μεγέθη

    Σύνδεση 1: KB sent: 1175.742188
    Σύνδεση 2: KB sent: 1025.820312
    Σύνολο: KB sent: 2201.5625

    Έχουμε μια μικρή βελτίωση στον συνολικά μεταφερθέντα όγκο κατά 23ΚΒ σε σχέση με τις δύο συνδέσεις με πακέτα των 1000bytes. Η βελτίωση αυτή είναι 1.06%, και οφείλεται στο μεγαλύτερα πακέτα.

    Δυστυχώς η βελτίωση αυτή, που είναι ελάχιστη, έρχεται με μεγάλο τίμημα στο latency και στο jitter.

    Σύνδεση 1
    Packets sent: 309
    Packets dropped: 10
    Total losses: 3.236246%

    Σύνδεση 2
    Packets sent: 272
    Packets dropped: 11
    Total losses: 4.044118%

    Αν αθροίσουμε τα παραπάνω έχουμε συνολικά 21 πακέτα χαμένα σε σύνολο 581 πακέτων. Αυτό σημαίνει μια συνολική απώλεια της τάξεως του 3.61% Αν το συγκρίνουμε με την περίπτωση πακέτων των 1000 bytes όπου είχαμε συνολική απώλεια 1.6%, βλέπουμε ότι τα πράγματα και εδώ χειροτερεύουν αισθητά.

    [break= Δύο συνδέσεις TCP (d)]
    2.3.d
    Από ότι είδαμε μέχρι τώρα το TCP μπορεί να προσαρμόζεται στις συνθήκες για την καλύτερη δυνατή εκμετάλλευση των δυνατοτήτων της γραμμής μας. Για να το κάνει αυτό όμως, στην αρχική φάση (και κατά την διάρκεια όταν υπάρχουν αλλαγές συναγωνιζόμενο άλλες συνδέσεις), κάνει "δοκιμές" για την ικανότητα της γραμμής και ανάλογα με τα αποτελέσματα προσπαθεί να προσαρμοστεί.

    Δυστυχώς αυτές οι "δοκιμές" μπορεί να έχουν σαν αποτέλεσμα διαγραφές πακέτων όταν αδυνατούν να περάσουν από την γραμμή και να συγκρατηθούν από τις buffers (είπαμε ότι έχουμε buffer των 20 πακέτων) και τα πακέτα είναι πολύ μεγάλα (και γι αυτό δεν προλαβαίνουν να βγουν από την buffer).

    Έτσι λοιπόν τα μεγάλα πακέτα, και μας δημιουργούν φαινόμενα διαγραφής, αλλά και η αναμετάδοση αυτών κατεβάζει επίσης την ταχύτητα.

    [break= Δύο συνδέσεις TCP (e)]
    2.3.e
    Τώρα για να δούμε τι γίνεται εάν αλλάξουμε την ταχύτητα της γραμμής και την κάνουμε μόνο 1Mbps δηλαδή το μισό και όλες οι υπόλοιπες παράμετροι είναι όπως στην αρχή του 2.3.

    Ας δούμε πρώτα την στιγμιαία ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3008.png 
Εμφανίσεις:  33 
Μέγεθος:  5,9 KB 
ID: 6461

    Έχουμε λοιπόν το ίδιο γράφημα με το 2.3.α όπου η γραμμή ήταν 2Mbps, απλά πέσαμε στις μισές ταχύτητες. Το γράφημα, σαν γράφημα, και η συμπεριφορά του TCP είναι ακριβώς ίδια!

    Ας δούμε και την συνολική ταχύτητα συστήματος.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3009.png 
Εμφανίσεις:  33 
Μέγεθος:  5,4 KB 
ID: 6426

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

    Ας συνεχίσουμε με το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3010.png 
Εμφανίσεις:  31 
Μέγεθος:  4,3 KB 
ID: 6427
    καμία διαφορά.

    Ας πάμε στο jittering

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3011.png 
Εμφανίσεις:  31 
Μέγεθος:  4,0 KB 
ID: 6428

    Μια από τα ίδια.

    Το συμπέρασμα που βγαίνει είναι ότι μειώνοντας την ταχύτητα της γραμμής, επηρεάζεται ανάλογα η συνολική ταχύτητα αλλά όχι το Latency / jitter. Φαίνεται λοιπόν ότι το latency και το jitter επηρεάζονται περισσότερο από την καθυστέρηση της γραμμής παρά από την ταχύτητά της (για το TCP πάντα).

    Ας δούμε και τα υπόλοιπα μεγέθη:

    Σύνδεση 1: KB sent: 552.539062
    Σύνδεση 2: KB sent: 539.335938
    Συνολικά: KB sent: 1091.8750

    Βλέπουμε λοιπόν ότι έχοντας δύο συνδέσεις έχουμε περίπου 10% λιγότερο από ότι με μια σύνδεση με όλες τις υπόλοιπες παραμέτρους ίδιες. Όμως γίνεται σχεδόν τέλεια αξιοποίηση της γραμμής.

    Ας δούμε και τις απώλειες

    Σύνδεση 1
    Packets sent: 557
    Packets dropped: 12
    Total losses: 2.154399%

    Σύνδεση 2
    Packets sent: 546
    Packets dropped: 14
    Total losses: 2.564103%

    Έχουμε λοιπόν μεγαλύτερες απώλειες από πριν.

    Όταν είχαμε 2Mbps, οι απώλειες ήταν 35 πακέτα στα 2182 ενώ τώρα έχουμε 28 πακέτα απώλειες στα 1103 δηλαδή έχουμε διπλάσιο σχεδόν ποσοστό.

    Πως γίνεται αυτό; Θυμηθείτε ότι έχουμε μια ουρά 20 πακέτων. Μόλις τα εισερχόμενα πακέτα στην ουρά δεν βρίσκουν χώρο, διαγράφονται (απώλειες). Αυτόματα και το TCP αυτορυθμίζεται (στην εκπομπή εφαρμογή, στην περίπτωση μας το FTP) να κατεβάσει ταχύτητα μετάδοσης. Οπότε αφού ξεκινά το TCP με τον ίδιο ρυθμό πάντα από την εφαρμογή, περιμένουμε ότι θα χάσει περίπου τα ίδια πακέτα στο αρχικό μπούκωμα της γραμμής. Εδώ μεγάλο ρόλο παίζει το μέγεθος της ουράς, και θα το δούμε μετά.

    [break= Δύο συνδέσεις TCP (f)]
    2.3.f
    Ας προχωρήσουμε λιγάκι, και ας δούμε σε συνέχεια των προηγουμένων το γίνεται αν αλλάξουμε την buffer και από 20 πακέτα την κάνουμε 50 πακέτα. Όλες οι υπόλοιπες παράμετροι όπως στο 2.3.α.

    Έτσι έχουμε σαν στιγμιαία ταχύτητα το παρακάτω γράφημα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3048.png 
Εμφανίσεις:  30 
Μέγεθος:  3,9 KB 
ID: 6429

    Παρατηρούμε πρώτα από όλα ότι έχουμε μια πιο ομαλή άνοδο της ταχύτητας χωρίς εκείνη την κοιλιά που είχαμε στα προηγούμενα παραδείγματα. Αυτό φαίνεται να είναι καλό. Λογικά πρέπει να έχουμε μικρότερες απώλειες. Άρα οι μεγαλύτερες buffers μειώνουν ή μηδενίζουν τα φαινόμενα απωλειών, και αυτό γιατί πλέον έχει τον χρόνο το TCP να προσαρμόσει την ταχύτητα εκπομπής πακέτων (στην εφαρμογή FTP στην περίπτωσή μας) μιας και η Buffer του δίνει αρκετό χρόνο χωρίς να χαθούν πακέτα (ή έστω πολλά). Όμως σύμφωνα με τα προηγούμενα, θα περιμένουμε ότι θα έχουμε και ανεβασμένο latency. Θα το δούμε στην συνέχεια.

    Υπάρχει μεγάλη βιβλιογραφία για την βέλτιστη buffer που πρέπει να έχουμε. Ενδεικτικά μπορείτε να δείτε ένα σχετικό pdf TCP Behavior with many flows ( Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  icnp97-web.pdf 
Εμφανίσεις:  61 
Μέγεθος:  226,6 KB 
ID: 6435 ) που είναι πολύ χρήσιμο ειδικά σε αυτούς που κάνουν χρήση P2P εφαρμογών με πολλές παράλληλες συνδέσεις (πχ Kazaa, emule κλπ).

    Μια συνήθης και αποτελεσματική πρακτική είναι ότι πρέπει να έχουμε τουλάχιστον 200ms της κίνησης να μπορεί να αποθηκευτεί σε buffers. Αυτό εξαρτάται βέβαια από την ταχύτητα. Έτσι σε μια γραμμή 2Mbps αντιστοιχία σε 51200 bytes. εάν τα πακέτα είναι των 1000 bytes, αυτό σημαίνει ότι πρέπει να έχουμε 51-52 πακέτα buffer. εάν όμως έχουμε realtime traffic τότε τα 200ms επιβαρύνουν με πολύ latency που δεν είναι επιθυμητό.

    Ας δούμε και την συνολική ταχύτητα του συστήματος.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3049.png 
Εμφανίσεις:  30 
Μέγεθος:  4,3 KB 
ID: 6430

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

    Ας δούμε τώρα και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3050.png 
Εμφανίσεις:  34 
Μέγεθος:  3,3 KB 
ID: 6431

    Λοιπόν αν το συγκρίνουμε με το latency στο 2.3.α, βλέπουμε ότι έχουμε πλέον latency σταθερότατο, αλλά αντί για 100ms έχουμε πάει στα 160ms (φυσικό είναι αφού πλέον έχουμε περισσότερα πακέτα στην ουρά). Όμως είναι σταθερό χωρίς σκαμπανεβάσματα.

    Άρα το jitter πρέπει να είναι μηδενικό.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3051.png 
Εμφανίσεις:  36 
Μέγεθος:  3,0 KB 
ID: 6432
    Ακριβώς!!. Μηδέν.

    Άρα μπορεί να έχει ανέβει το latency, αλλά με μηδενικό jitter είναι καλύτερα τα πράγματα. Βλέπουμε λοιπόν ότι όταν έχουμε μεγαλύτερες buffers, σε πολλές συνδέσεις TCP, γίνεται καλύτερη αξιοποίηση και συμπεριφορά. Για να καταλάβουμε αυτή την συμπεριφορά θα πρέπει να δούμε τι γίνεται με την buffer.

    Πρώτα ας δούμε πως είναι στην περίπτωση 2.3.α με buffer δηλαδή 20 πακέτων.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3052.png 
Εμφανίσεις:  29 
Μέγεθος:  5,4 KB 
ID: 6433

    Βλέπουμε λοιπόν μια έντονα παλινδρομική συμπεριφορά. Βλέπουμε ότι οι κορυφές (στα 9 πακέτα) και στις δύο συνδέσεις καταλήγουν σε ένα άθροισμα περίπου στα 18-19 πακέτα την δεδομένη στιγμή, Άρα φτάνουμε σε αυτό το όριο γιατί προφανώς εκτελείται drop-tail, δηλαδή διαγραφή πακέτων. Και εάν θυμάστε από το 2.3.α, όντως είχαμε απώλειες. Δηλαδή η buffer δεν φτάνει.

    Τώρα στην περίπτωση με buffer χωρητικότητας πλέον 50 πακέτων, έχουμε το γράφημα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3053.png 
Εμφανίσεις:  34 
Μέγεθος:  3,9 KB 
ID: 6434

    Εδώ βλέπουμε και πάλι βέβαια παλινδρομήσεις αλλά πολύ μικρότερες σε εύρος και το σημαντικότερο, δεν πιάνουμε οροφή. Η ανώτερη κατάληψη buffer για κάθε σύνδεση είναι 17 πακέτα, άρα συνολικά 34 πακέτα. Αυτό σημαίνει ότι ποτέ δεν εφαρμόζεται drop tail, και πρέπει να περιμένουμε να έχουμε μηδενικές απώλειες (θα το δούμε παρακάτω).

    Ας δούμε και τα συνολικά μεγέθη:

    Σύνδεση 1: KB sent: 1228.945312
    Σύνδεση 2: KB sent: 1216.757812
    Συνολικά: KB sent: 2445.703124

    εάν το συγκρίνουμε με την περίπτωση 2.3.α που η μόνη διαφορά είναι το μέγεθος της buffer βλέπουμε ότι έχουμε μια διαφορά στο συνολικό όγκο (εκεί είχαμε 2178.593750KB) δηλαδή έχουμε μια διαφορά +12.26%. Το συμπέρασμα που βγαίνει από αυτό είναι ότι αυξάνοντας το μέγεθος της buffer αυξάνουμε και την ικανότητα μεταφοράς της γραμμής.

    Αν το συγκρίνουμε μάλιστα με την αντίστοιχη περίπτωση με μία σύνδεση TCP και πάλι buffer των 50 πακέτων θα δούμε ότι εκεί είχαμε 2421.289062KB. Δηλαδή με δύο συνδέσεις τα πήγαμε καλύτερα, και μάλιστα κατά 1.008%. Μπορεί να είναι μικρή η διαφορά, αλλά μας δείχνει ότι έχουμε ακόμη καλύτερη αξιοποίηση της γραμμής με δύο συνδέσεις, αρκεί να μην υπάρχει κορεσμός στις buffers.

    Ας δούμε τελικά και τις απώλειες:

    Σύνδεση 1
    Packets sent: 1211
    Packets dropped: 0
    Total losses: 0.000000%

    Σύνδεση 2
    Packets sent: 1199
    Packets dropped: 0
    Total losses: 0.000000%

    Αυτό που είχαμε πει και πιο πριν μελετώντας την ουρά. Απ ότι βλέπουμε, δεν έχουμε απώλειες...

    [break= Δύο συνδέσεις TCP (g)]
    2.3.g
    Στο προηγούμενο είδαμε την συμπεριφορά με Buffers των 50 πακέτων. Για να δούμε τι γίνεται εάν μειώσουμε σε 5 πακέτα την buffer! Λογικό είναι να περιμένουμε ότι θα υπάρχει κορεσμός στην buffer. Αφού θα γεμίζει, μάλλον θα έχουμε και απώλειες, και λογικά αυτό πρέπει να επηρεάσει και το συνολικό bandwidth. Εφόσον η ουρά θα είναι μικρή, το Latency λογικά θα πρέπει να περιμένουμε να είναι μικρό. Και σίγουρα όπου προκύπτουν διαγραφές πακέτων θα πρέπει να ανεβαίνει. Ας τα δούμε όμως όπως πραγματικά βγήκαν από τις μετρήσεις και να δούμε πόσο η λογική μας έπεσε κοντά στην πραγματικότητα.

    Πρώτα από όλα ας δούμε την στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3076.png 
Εμφανίσεις:  37 
Μέγεθος:  5,1 KB 
ID: 6436

    Συγκρίνοντας με την περίπτωση 2.3.α όπου είχαμε buffer χωρητικότητας 20 πακέτων προκύπτουν τα εξής συμπεράσματα:

    α) Πρώτα είχαμε μια παλινδρόμηση από τα 1600 έως τα 1800 Kbps ενώ τώρα βλέπουμε ότι η παλινδρόμηση συμβαίνει μεταξύ των 1400 και 1600 Κbps. Αυτό σίγουρα επηρεάζει την συνολική ταχύτητα.
    β) Βλέπουμε ότι τώρα οι αυξομειώσεις είναι πολύ πυκνές, δηλαδή συμβαίνουν πολλές περισσότερες στην ίδια μονάδα χρόνου. Βλέπουμε ότι η μία σύνδεση ξεπερνά την άλλη και όλα αυτά φυσικά επειδή έχουμε πλέον πολύ μικρή buffer.

    Ας δούμε και την συνολική ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3077.png 
Εμφανίσεις:  35 
Μέγεθος:  5,0 KB 
ID: 6437

    Βλέπουμε λοιπόν ότι έχουμε πλέον ένα πολύ έντονο επεισόδιο αρχικής απώλειας πακέτων (με την προσπάθεια αναπροσαρμογής της ταχύτητας του TCP που είναι η καμπύλη μέχρι την εξισορρόπηση). Βλέπουμε επίσης ότι η μία σύνδεση ( η πράσινη) παίρνει περισσότερο bandwidth από την άλλη, σχεδόν 200 Kbps. Άρα από εδώ συμπεραίνουμε ότι εκτός από την μικρότερη ταχύτητα, μειώνοντας το μέγεθος της buffer, έχουμε πλέον και άνιση μεταχείριση στις συνδέσεις.

    Ας δούμε όμως το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3078.png 
Εμφανίσεις:  31 
Μέγεθος:  3,5 KB 
ID: 6438

    Όπως προείπαμε. Έχοντας μικρότερη ουρά, το latency μειώθηκε αισθητά. Έχουμε μόνο μια μεγάλη διακύμανση στο αρχικό δευτερόλεπτο όπου συμβαίνει η απώλεια ταχύτητας. Όντας πολύ μικρό το latency, οι διακυμάνσεις του είναι επίσης μικρές.

    Όπως βλέπουμε από το παρακάτω γράφημα του jitter

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3079.png 
Εμφανίσεις:  35 
Μέγεθος:  3,7 KB 
ID: 6439

    εκτός στο πρώτο δευτερόλεπτο, είναι κατά κανόνα κοντά στο μηδέν.

    Άρα μειώνοντας την buffer, έχουμε σημαντικά μικρότερο latency και jitter Αλλά με τίμημα την ταχύτητα και τις απώλειες.

    Στα συνολικά μεγέθη έχουμε

    Σύνδεση 1: KB sent: 940.507812
    Σύνδεση 2: KB sent: 1180.195312
    Συνολικά: KB sent: 2120.703124

    Βλέπουμε λοιπόν ότι έχουμε μια μείωση του συνολικού όγκου που μεταφέρθηκε κατά 2.66 % από ότι όταν είχαμε buffer με 20 πακέτα. Και όχι μόνο Αυτό. Είχαμε περίπου τον ίδιο όγκο για κάθε σύνδεση ( 51% - 49%) ενώ εδώ βλέπουμε 44.34% - 55.66%

    Τελευταία ας δούμε τις απώλειες:

    Σύνδεση 1
    Packets sent: 978
    Packets dropped: 51
    Total losses: 5.214724%

    Σύνδεση 2
    Packets sent: 1210
    Packets dropped: 47
    Total losses: 3.884298%

    Όπως ακριβώς το σκεφτήκαμε στην αρχή, ότι δηλαδή θα έχουμε απώλειες.

    Μάλιστα παρατηρούμε ότι η σύνδεση 1 (κόκκινο) έχει περισσότερες απώλειες και από εδώ φαίνεται επίσης ότι έχει μικρότερο bandwidth (άνιση κατανομή). εάν είχαμε γράφημα για την ουρά θα βλέπαμε ότι πρώτη η μια σύνδεση κάνει drop tail (η κόκκινη) και γι αυτό παρουσιάζει περισσότερες απώλειες και τελικά και μικρότερο bandwidth ( τα 200Kbps λιγότερο που βλέπαμε ).

    Επίσης εάν το συγκρίνουμε με την περίπτωση 2.3.α, εκεί είχαμε συνολικές απώλειες στο 1,6% ενώ εδώ φτάνουμε 4.48%. Σαν συμπέρασμα των παραπάνω, βλέπουμε ότι σε κάθε περίπτωση, οι μεγάλες buffers βοηθούν το TCP ώστε να έχει καλύτερη αξιοποίηση της γραμμής.

    [break= Δύο συνδέσεις TCP (h)]
    2.3.h

    Άντε λίγο ακόμα και τελειώνουμε και τις δύο συνδέσεις TCP. Σαν τελευταία δοκιμή, Όπως θα ξέρετε ίσως όλοι όσοι έχετε παρακολουθήσει τα προηγούμενα ως εδώ, είναι να χρησιμοποιήσουμε τις παραμέτρους του 2.3.α αλλά με καθυστέρηση γραμμής 100ms αντί για 10 ms.

    Τι παρατηρούμε στο παραπάνω γράφημα της στιγμιαίας ταχύτητας;

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3080.png 
Εμφανίσεις:  32 
Μέγεθος:  4,1 KB 
ID: 6440

    Βλέπουμε κατ' αρχήν ότι οι παλινδρομήσεις είναι πιο ομαλές μεταξύ 1700 και 1900 Kbps. Αν θυμάστε από το 2.1, εάν έχουμε μεγαλύτερη καθυστέρηση στην γραμμή μειώνεται η ταχύτητα. από την άλλη όμως μεγαλύτερη καθυστέρηση στην γραμμή, σημαίνει ότι έχουμε περισσότερα πακέτα να βρίσκονται κάθε χρονική στιγμή επάνω σε αυτή ταξιδεύοντας, οπότε έχουμε μια λειτουργία σαν buffer.

    Στα 100ms μιας 2Mbps γραμμής υπάρχουν περίπου 26 πακέτα. Αυτό βγαίνει ως εξής: Bandwidth *( χρόνος ) / ( μέγεθος πακέτου) = (2Mbps*1024* 1024 / 8) * ( 100 ms / 1000 ) / 1000 = 26,2 Άρα μαζί με τα 20 πακέτα που χωρά η κανονική buffer είναι σαν να έχουμε συνολική buffer των 50 περίπου πακέτων.

    Ας δούμε όμως και την συνολική ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3081.png 
Εμφανίσεις:  29 
Μέγεθος:  4,9 KB 
ID: 6441

    Αν το συγκρίνουμε με το 2.3.α, έχουμε μια πιο ομαλή συμπεριφορά, χωρίς εκείνο το κενό στο 1ο δευτερόλεπτο. Βλέπουμε όμως ότι αργεί να αυξήσει την ταχύτητα, και μετά 10 δεύτερα μόλις έχει φτάσει στα 700 περίπου kbps. Συμπεραίνουμε λοιπόν ότι όταν έχουμε μεγαλύτερη καθυστέρηση γραμμής, μειώνονται και εξομαλύνονται τα επεισόδια παλινδρομήσεων, μιας και η καθυστέρηση αυτή λειτουργεί και ως buffer, αλλά μειώνεται και η απόδοση του συστήματος.

    Ας δούμε και το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3082.png 
Εμφανίσεις:  31 
Μέγεθος:  3,5 KB 
ID: 6442

    Τώρα πια εύκολα θα το έχετε αντιληφθεί, ότι αφού έχουμε μεγαλύτερη καθυστέρηση γραμμής θα έχουμε και μεγαλύτερο latency. Για την ακρίβεια βλέπουμε μια σταθερή τιμή, στα 104ms. Αν όμως έχουμε 100ms στην γραμμή, τότε όλοι οι υπόλοιποι παράγοντες μας βάζουν μόνο 4ms. Άρα δηλαδή θα πρέπει να έχουμε μικρή κατάληψη στην buffer.

    Για να δούμε το γράφημα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3083.png 
Εμφανίσεις:  32 
Μέγεθος:  3,8 KB 
ID: 6443

    Όπως το φανταστήκαμε. Έχουμε λιγότερο από 1 πακέτο στην Buffer, εκτός από την αρχή που προσπαθεί να προσαρμοσθεί το TCP. γι αυτό και έχουμε σχεδόν την καθυστέρηση της γραμμής για latency.

    Και φυσικά με μια τέτοια σταθερή τιμή, λογικό είναι να περιμένουμε ότι και το jitter θα είναι μηδενικό.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3084.png 
Εμφανίσεις:  26 
Μέγεθος:  3,1 KB 
ID: 6444

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

    Ας δούμε και τα συνολικά μεγέθη:

    Σύνδεση 1: KB sent: 924.257812
    Σύνδεση 2: KB sent: 908.007812
    Συνολικά: KB sent: 1832.265624

    Αν δείτε έχουμε μια μείωση της ταχύτητας σε σχέση με την περίπτωση 2.3.α της τάξεως του 15.89% και βέβαια αυτό οφείλεται αποκλειστικά στην αύξηση της καθυστέρησης της γραμμής. Μπορεί η καθυστέρηση της γραμμής να λειτουργεί ως buffer και να εξομαλύνει τις παλινδρομήσεις, αλλά σε καμία περίπτωση δεν αντικαθιστά την κανονική Buffer (πχ 50 πακέτων).

    Ας δούμε και τις απώλειες:

    Σύνδεση 1
    Packets sent: 911
    Packets dropped: 0
    Total losses: 0.000000%

    Σύνδεση 2
    Packets sent: 895
    Packets dropped: 0
    Total losses: 0.000000%

    Όπως είπαμε και στην αρχή, η καθυστέρηση της γραμμής λειτουργώντας ως μεγαλύτερη buffer, μας έδωσε την δυνατότητα να μην έχουμε απώλειες, μιας και προσαρμόζεται πλέον πιο γρήγορα το TCP στο νέο τοπίο. Έχουμε όμως σημαντική πτώση της ταχύτητας (στο 2.3.α είχαμε συνολικά 2147 πακέτα έναντι των 1806 πακέτων εδώ).

    Εάν το συγκρίνουμε με την περίπτωση buffers 50 πακέτων τα αποτελέσματα είναι ακόμη χειρότερα. Όπως βλέπουμε αυτή η "buffer" δεν δίνει τα ίδια πλεονεκτήματα με την κανονική, και επιβαρύνει σημαντικά την συνολική ταχύτητα και το latency.

    [break= Δύο συνδέσεις UDP]
    2.4 Δύο συνδέσεις UDP
    Νά μαστε λοιπόν στο επόμενο κεφάλαιο, και θα δούμε τι συμβαίνει με δύο συνδέσεις UDP. Όπως έχουν επισημάνει κάποιοι συνάδελφοι εδώ, θα πρέπει να σημειώσουμε ότι αυτά που αναλύονται είναι κάτω από ιδεατές συνθήκες με ένα πρόγραμμα προσομοίωσης. γι αυτό και μπορούμε να αλλάξουμε κάποιες παραμέτρους και να βλέπουμε με ακρίβεια τι συμβαίνει.

    Στην πραγματικότητα όμως όπως πχ στις ADSL συνδέσεις οι παράμετροι είναι περισσότερες, καθώς επίσης και το τι περνάει από την γραμμή (εκτός των συνδέσεων μας, υπάρχουν και multicast / broadcast πακέτα, πακέτα που έρχονται από hackers που προσπαθούν να κάνουν portscanning, ή αν έχουν βρει κάποιες πόρτες να προσπαθούν να μπουν και όλα αυτά χωρίς καμία δραστηριότητα από εμάς και πολλά άλλα).

    Άρα στην πραγματικότητα ποτέ μια γραμμή ADSL δεν είναι idle (εκτός αν βγάλουμε από την πρίζα τον router / modem). Επίσης θα πρέπει να πούμε και το εξής. Τα πακέτα μας είτε TCP είτε UDP είτε οτιδήποτε άλλο (δηλαδή τα IP πακέτα μας) με το που θα φθάσουν στο router θα γίνουν encapsulate σε άλλο πακέτο τύπου PPP.

    Εκεί υπάρχουν επίσης πολλά θέματα, που όμως επηρεάζουν σημαντικά τις real time εφαρμογές όπως το VoIP, και ίσως αποτελέσει άλλο νήμα (και άλλη θεωρία, ούφφφφφ... ) όπως για παράδειγμα το MTU size, packet fragmentation, και πως την πατάνε τα μικρά πακέτα (στο latency) όταν κυκλοφορούν και μεγάλα πακέτα και εάν μπορεί να αντιμετωπιστεί και πολλά άλλα. Όσοι θέλετε να βοηθήσετε, και έχετε χρόνο, ελάτε....

    Τώρα στο θέμα μας. Έχουμε λοιπόν ένα κύκλωμα όπως το παρακάτω σχήμα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3095.gif 
Εμφανίσεις:  30 
Μέγεθος:  2,7 KB 
ID: 6445

    Δηλαδή έχουμε μια γραμμή ταχύτητας 2Mbps, και δύο συνδέσεις UDP με σταθερή ροή 0.95Mbps η κάθε μία. Τα πακέτα είναι μεγέθους 1000 bytes, η γραμμή έχει μια καθυστέρηση 10ms. Επίσης υπάρχει μια buffer χωρητικότητας 20 πακέτων. Η ουρά λειτουργεί FIFO και με στρατηγική διαγραφής drop tail. Τα έχουμε εξηγήσει αυτά πιο πριν, άρα δεν θα επεκταθούμε εδώ παραπάνω.

    Λοιπόν πρώτα θα δούμε την στιγμιαία ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3096.png 
Εμφανίσεις:  38 
Μέγεθος:  3,0 KB 
ID: 6446

    Βλέπουμε μόνο μια πράσινη γραμμή, και αυτό γιατί πρώτα "βάφει" με την κόκκινη (σύνδεση 1), και μετά την πράσινη (σύνδεση 2) και επειδή συμπίπτουν, η πράσινη γραμμή "καπακώνει" την κόκκινη. Με απλά λόγια αφού εξηγήσαμε τι συμβαίνει με τα χρώματα, έχουμε ακριβώς την ίδια συμπεριφορά.

    Ας δούμε και την συνολική ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3097.png 
Εμφανίσεις:  40 
Μέγεθος:  3,3 KB 
ID: 6447

    Και εδώ βλέπουμε ότι κάθε σύνδεση πιάνει τα 900Kbps (ελάχιστες μικροδιαφορές κάνουν ορατή την κόκκινη γραμμή).

    Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3098.png 
Εμφανίσεις:  32 
Μέγεθος:  3,1 KB 
ID: 6448

    Βλέπουμε ότι έχουμε σταθερό latency, 14ms για την πρώτη σύνδεση (κόκκινο) και 18ms για την δεύτερη σύνδεση (πράσινο). Σε αντιδιαστολή όταν είχαμε δύο TCP συνδέσεις, είχαμε το ίδιο latency και ήταν περίπου 80ms.

    Και αφού το latency είναι σταθερό, περιμένουμε να έχουμε και μηδέν jitter.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3099.png 
Εμφανίσεις:  29 
Μέγεθος:  3,5 KB 
ID: 6449

    Ακριβώς!!! (Το πράσινο και πάλι καπακώνει το κόκκινο). Δηλαδή δεν έχουμε καθόλου jitter.

    Ας δούμε και τα συνολικά μεγέθη:

    Σύνδεση 1: KB sent: 1148.437500
    Σύνδεση 2: KB sent: 1148.437500
    Συνολικά: KB sent: 2296.875000

    Βλέπουμε ότι αφού δεν ανταγωνίζονται για το bandwidth, και οι δύο συνδέσεις αξιοποιούν πλήρως την γραμμή. Έχουμε ακριβώς τον ίδιο όγκο με μία σύνδεση UDP των 1900 Kbps CBR.

    Φαίνεται λοιπόν ότι αν ξέρουμε εκ των προτέρων πόσο bandwidth χρειαζόμαστε και μας καλύπτει η γραμμή μας σε αυτό, το UDP δείχνει καλύτερη συμπεριφορά.

    Τελευταία ας δούμε και τις απώλειες:

    Σύνδεση 1
    Packets sent: 1176
    Packets dropped: 0
    Total losses: 0.000000%

    Σύνδεση 2
    Packets sent: 1176
    Packets dropped: 0
    Total losses: 0.000000%

    Καθόλου απώλειες, και όλα φαίνονται τέλεια (αν ήταν έτσι πάντα τα πράγματα)

    [break= Δύο συνδέσεις UDP (b)]
    2.4.b
    Είδαμε λοιπόν τι καλά πάει το UDP στο προηγούμενο παράδειγμα. Για να αρχίζουμε να παίζουμε με τις παραμέτρους να δούμε πως ανταποκρίνεται. Πρώτα από όλα θα παίξουμε με το μέγεθος του πακέτου. Θα κάνουμε τα πακέτα από 1000 bytes σε 100 bytes.

    Λογικά, τι πρέπει να περιμένουμε με βάση τα προηγούμενα που έχουμε μάθει; Είχαμε δει και πιο πριν ότι στο UDP μικραίνοντας το πακέτο, βελτιώνεται η ανταπόκρισή του στο latency (μικρότερη καθυστέρηση).

    Για να μην επαναλαμβανόμαστε, θα έχουμε την ίδια στιγμιαία ταχύτητα και συνολική ταχύτητα συστήματος (υπάρχει πολύ - μα πολύ μικρή διαφορά, για τους περφεξιονίστες που μπορεί να μου την βγουν ).

    Εκεί που υπάρχει κάποια διαφοροποίηση είναι στο latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3115.png 
Εμφανίσεις:  32 
Μέγεθος:  3,3 KB 
ID: 6450

    Όπως βλέπουμε αντί για 18 και 14 ms, τώρα έχουμε 10.8 και 10.4 ms. Η διαφορά είναι εμφανής. Πριν είχαμε διαφορά μεταξύ τους 4ms, τώρα έχουμε 0.4ms. Και σημειώστε ότι είμαστε πλέον πολύ κοντά, σχεδόν το ίδιο, με την καθυστέρηση της γραμμής που είναι 10ms.

    Να γιατί προτιμούν σε real time εφαρμογές, μικρά πακέτα UDP. Φεύγουν σφαίρα (αν υπάρχει χώρος στην γραμμή, έτσι...) Τώρα πως προκύπτει το 10.4 και 10.8 εάν υπολογίσουμε πόσο χρόνο κάνει να περάσει ένα πακέτο των 100 bytes από μια γραμμή των 2Mbps, έχουμε 0,42 ms Δηλαδή αυτό που βρήκαμε.

    Αυτό σημαίνει ότι δεν χρησιμοποιείται καθόλου η ουρά. Με το που έρχεται από την πρώτη σύνδεση το πακέτο φεύγει για απέναντι. Συνολικός χρόνος 10.4 ms. Ταυτόχρονα όμως έχει έρθει και το άλλο πακέτο από την άλλη σύνδεση. Αυτό περιμένει στην buffer για 0.4ms μέχρι να φύγει το πρώτο, και μετά φεύγει και αυτό σε χρόνο, πολύ σωστά μαντέψατε 0.4ms!

    Άρα το πακέτο της δεύτερης σύνδεσης έκανε συνολικά 0.4ms που περίμενε + 10ms καθυστέρηση γραμμής + 0.4ms να περάσει από το "σύρμα" = 10.8 ms !!! Ομοίως μπορεί να υπολογιστεί και για τα πακέτα των 1000 bytes, και αφήνετε ως άσκηση για τον αναγνώστη

    Αφού λοιπόν βλέπουμε ότι έχουμε ένα τέτοιο latency, λογικό είναι να έχουμε και jitter μηδενικό.

    Ας δούμε και τα συνολικά μεγέθη:

    Σύνδεση 1: KB sent: 1148.144531
    Σύνδεση 2: KB sent: 1148.144531
    Συνολικά: KB sent: 2296.289062

    Βλέπουμε σχεδόν τα ίδια νούμερα με τα πακέτα των 1000 bytes. Για την ακρίβεια μειώθηκε ο συνολικά μεταφερθέν όγκος κατά 0.5 ΚΒ περίπου. Όμως έχουμε κερδίσει σημαντικά στο latency, άρα μας συμφέρει περισσότερο να έχουμε μικρά πακέτα, παρά μεγάλα. Φυσικά λογικό είναι να μην έχουμε καθόλου απώλειες (αφού δεν υπάρχει κορεσμός).

    [break= Δύο συνδέσεις UDP (c)]
    2.4.c
    Τώρα θα δοκιμάσουμε με μεγάλα πακέτα, των 4000 bytes, να δούμε τι συμβαίνει.

    Πρώτα από όλα θα δούμε την στιγμιαία ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3116.png 
Εμφανίσεις:  30 
Μέγεθος:  3,1 KB 
ID: 6451

    Βλέπουμε ότι δεν υπάρχει ουσιαστική διαφορά με τις προηγούμενες περιπτώσεις. Κάποιες μικροδιαφορές που προκύπτουν φαίνονται και στο γράφημα, που πλέον εμφανίζονται κάποια κόκκινα σημεία...

    Ας δούμε και την συνολική ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3117.png 
Εμφανίσεις:  30 
Μέγεθος:  3,3 KB 
ID: 6452

    Όπα εδώ τι γίνεται; Έχουμε μια μικρή κορυφή στην αρχή που είναι απλά λόγω του μεγάλου πακέτου που στέλνει πρώτο η κόκκινη σύνδεση, αλλά αμέσως προσαρμόζεται, και έχουμε και τις δύο συνδέσεις στα 900 περίπου Kbps. Το ότι κάνει σαν κοιλιά η κόκκινη σύνδεση είναι από την εξομάλυνση του γραφήματος.

    Να και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3118.png 
Εμφανίσεις:  29 
Μέγεθος:  3,0 KB 
ID: 6453

    Ο υπολογισμός αφήνετε στον αναγνώστη, και φυσικά οφείλεται όπως είπαμε και πιο πριν στην καθυστέρηση της γραμμής και στο χρόνο που κάνει να περάσει από το σύρμα το μεγάλο πλέον πακέτο των 4000 bytes. Το δε πακέτο της πράσινης σύνδεσης πρέπει να περιμένει την σειρά μετά από αυτό της κόκκινης σύνδεσης, και γι αυτό έχει μεγαλύτερο latency. Όμως και πάλι είναι σημαντικά μικρότερο από το αντίστοιχο του TCP.

    Φυσικά το jitter θα είναι μηδενικό
    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3119.png 
Εμφανίσεις:  32 
Μέγεθος:  3,5 KB 
ID: 6454

    Ακριβώς!!.

    Και για τα συνολικά μεγέθη θα έχουμε:

    Σύνδεση 1: KB sent: 1148.437500
    Σύνδεση 2: KB sent: 1148.437500
    Συνολικά: KB sent: 2296.875000

    Και όσο για τις απώλειες θα είναι και πάλι μηδενικές.

    [break= Δύο συνδέσεις UDP (d)]
    2.4.d
    Σας άφησα λίγο, έχω αρχίσει να βαραίνω, αλλά πρέπει να συνεχίσουμε. Μέχρι τώρα είδαμε τις δύο συνδέσεις UDP, και οποίες δεν έχουν πρόβλημα με τις αλλαγές του μεγέθους του πακέτου,

    Αλλά είδαμε και πόσο καλύτερα συμπεριφέρεται με μικρά πακέτα. Για να δούμε όμως τι γίνεται εάν "ζορίσουμε" τα UDP δημιουργώντας τεχνητά , προβλήματα congestion. Σαν πρώτη δοκιμή, θα περιορίσουμε την ταχύτητα της γραμμής στο 1Mbps ενώ όλες οι υπόλοιπες παράμετροι είναι όπως στο 2.3.α.

    Ας δούμε λοιπόν την στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3152.png 
Εμφανίσεις:  30 
Μέγεθος:  4,0 KB 
ID: 6455

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

    Και οι δύο συνδέσεις στέλνουν συνεχώς με 0.95 Mbps, αλλά από την γραμμή μπορούν να περάσουν μόνο μέχρι 1Mbps το πολύ. Άρα κάποια πακέτα τα τρώει το μαύρο το σκοτάδι. Και οι δύο συνδέσεις ανεβαίνουν ταχύτητα όπως και στα προηγούμενα παραδείγματα μέχρι τα 500Kbps (σύνολο 1Mbps) και μετά όπως είναι φυσικό, υπάρχει congestion, δεν μπορούν να περάσουν όλα από την γραμμή.

    Τα πακέτα της μιας σύνδεσης (κόκκινη - πρώτη σύνδεση ) περνάνε και φτάνουν στο όριο των 0.95Mbps αλλά με κάποιες παλινδρομήσεις, ενώ η δεύτερη σύνδεση "γονατίζει" κάτω και παίρνει ότι περισσεύει, μαχόμενη να στείλει πακέτα (γι αυτό και οι παλινδρομήσεις της πρώτης).

    Για να το καταλάβουμε καλύτερα αυτό, θα πρέπει να δούμε την ουρά των πακέτων στην buffer.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3153.png 
Εμφανίσεις:  30 
Μέγεθος:  3,7 KB 
ID: 6456

    Εδώ τι βλέπουμε; Γεμίζει η buffer με 18 πακέτα της κόκκινης σύνδεσης (πρώτη σύνδεση), και έχει μόνο 2 πακέτα από την πράσινη. Άρα πρώτα από όλα ότι πακέτο έρχεται για την πράσινη σύνδεση γίνεται drop tailed. Διαγράφεται.

    Αν κάνουμε κάποιους υπολογισμούς πολύ απλούς με το πόσα πακέτα διατηρεί σταθερά από την κάθε σύνδεση στην ουρά βλέπουμε ότι έχει (18/20) * 1Μbps = 0.9 Mbps για την πρώτη σύνδεση και (2/20) * 1Mbps = 100Κbps για την δεύτερη που επαληθεύεται.

    Ας δούμε λοιπόν και το γράφημα της συνολικής ταχύτητας.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3154.png 
Εμφανίσεις:  29 
Μέγεθος:  3,9 KB 
ID: 6457

    Bingo. Όπως ακριβώς είπαμε και πιο πάνω.

    Ας δούμε και το latency.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3155.png 
Εμφανίσεις:  31 
Μέγεθος:  3,6 KB 
ID: 6458

    Βλέπουμε ότι το latency ανέβηκε πολύ και αυτό είναι αναμενόμενο μιας και χρησιμοποιείται πλέον όλη η buffer. Έχουμε δηλαδή 20 πακέτα των 1000 Bytes, που σημαίνει ότι αυτά για να περάσουν από την γραμμή του 1Mbps χρειάζονται συνολικά 160ms. Συν άλλα 10 ms που είναι η καθυστέρηση γραμμής και έχουμε κατευθείαν 170ms.

    Φυσικά δεν περιμένουμε και τέλεια αποτελέσματα στο jitter μιας και το latency δεν είναι μια σταθερή (λεπτή) γραμμή

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3156.png 
Εμφανίσεις:  33 
Μέγεθος:  2,8 KB 
ID: 6459

    Έτσι βλέπουμε λοιπόν ότι έχουμε λίγο jitter.

    [break= Δύο συνδέσεις UDP (e)]
    2.4.e
    Από τα προηγούμενα βγαίνει το συμπέρασμα ότι το UDP είναι καλό σαν πρωτόκολλο, όταν γνωρίζουμε την διαθέσιμη χωρητικότητα του καναλιού και μπορεί η σύνδεση να γίνει χωρίς να "μπουκώνει". Διαφορετικά τα αποτελέσματα είναι πολύ χάλια για να μπορεί να χρησιμοποιηθεί για real time εφαρμογές.

    Αν δούμε και τα συγκεντρωτικά αποτελέσματα για το παράδειγμα της 2.4.d έχουμε:

    Σύνδεση 1: KB sent: 1148.437500
    Σύνδεση 2: KB sent: 78.125000
    Συνολικά: KB sent: 1226.562500

    Βλέπουμε λοιπόν ότι η σύνδεση 1, κατάφερε να στείλει όσα και στο παράδειγμα 2.3.α, δηλαδή όλα τα πακέτα. Η δεύτερη σύνδεση όμως έστειλε μόνο 78ΚΒ, δηλαδή πολύ χάλια.

    Από αυτό συμπεραίνουμε εύκολα τι θα συμβαίνει στις απώλειες:

    Σύνδεση 1
    Packets sent: 1176
    Packets dropped: 0
    Total losses: 0.000000%

    Σύνδεση 2
    Packets sent: 1176
    Packets dropped: 1096
    Total losses: 93.197279%

    Λογικό και αναμενόμενο. Η δεύτερη σύνδεση είχε όλες τις απώλειες.

    [break= Δύο συνδέσεις UDP (f)]
    2.4.f
    Σε αυτό το παράδειγμα, θα παίξουμε με το μέγεθος της buffer και από 20 πακέτα που έχει χωρητικότητα θα το κάνουμε 50. Τώρα αν έχετε δει προσεκτικά το 2.4.α θα έχετε προσέξει ότι δεν κάνουμε ουσιαστική χρήση της buffer, οπότε λογικά θα περιμένουμε ότι δεν θα έχει διαφορά η αύξηση αυτή.

    Και πραγματικά για να μην κουράζουμε τον αναγνώστη, έχουμε ακριβώς τα ίδια αποτελέσματα με το 2.4.α

    Ας δούμε μόνο το γράφημα που αφορά τα πακέτα στην buffer.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3203.png 
Εμφανίσεις:  29 
Μέγεθος:  3,4 KB 
ID: 6460

    Έχουμε το ίδιο γράφημα είτε η έχουμε Buffer 20 πακέτων είτε 50. Και αυτό γιατί, αφού η κατάληψη είναι πολύ μικρή (λιγότερο από ένα πακέτο), τι 20 τι 50.

    Ομοίως για να μην ανοίγουμε καινούργιο κεφάλαιο συμβαίνει εάν μειώσουμε την buffer στα 5 πακέτα. Αν και έχουμε δει πόσο δραματική αλλαγή είναι αυτή στο TCP, στο UDP, εφόσον μπορούν να περνούν τα πακέτα, η κατάληψη είναι το πολύ ένα πακέτο στην ουρά, άρα και με buffer 5 πακέτων δεν έχουμε απολύτως καμία διαφορά.

    [break= Δύο συνδέσεις UDP (g)]
    2.4.g

    Σαν τελευταία δοκιμή, ας δούμε τι συμβαίνει εάν αυξηθεί η καθυστέρηση της γραμμής από 10ms σε 100ms.

    Ας δούμε πρώτα την στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3204.png 
Εμφανίσεις:  33 
Μέγεθος:  3,1 KB 
ID: 6471

    Βλέπουμε ότι πιάνει την ίδια "τελική" αλλά ελάχιστα πιο αργά από πριν.

    Ας δούμε και την συνολική ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3205.png 
Εμφανίσεις:  34 
Μέγεθος:  3,6 KB 
ID: 6472

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

    Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3206.png 
Εμφανίσεις:  33 
Μέγεθος:  3,2 KB 
ID: 6473

    Φυσικά το jitter θα είναι μηδενικό

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  3207.png 
Εμφανίσεις:  31 
Μέγεθος:  3,5 KB 
ID: 6474

    Ας δούμε και τα συνολικά μεγέθη, πόσος όγκος διακινήθηκε:

    Σύνδεση 1: KB sent: 1148.437500
    Σύνδεση 2: KB sent: 1148.437500
    Συνολικά: KB sent: 2296.875000

    H μεγαλύτερη καθυστέρηση δεν επηρεάσε καθόλου το UDP!

    Ας δούμε τώρα και τίς απώλειες:

    Σύνδεση 1
    Packets sent: 1176
    Packets dropped: 0
    Total losses: 0.000000%

    Σύνδεση 2
    Packets sent: 1176
    Packets dropped: 0
    Total losses: 0.000000%

    Θαυμάσια και οι 2 συνδέσεις έστειλαν τον ίδιο αριθμό πακέτων χωρίς απώλειες!

    Επομένως πέρα απο την μικρή καθυστέρηση στην αρχή κανένα άλλο πρόβλημα δεν δημιουργήθηκε!

    [break= Μια σύνδεση TCP και μια σύνδεση UDP (a)]

    2.5.a Μια σύνδεση TCP και μια σύνδεση UDP


    Επιτέλους είναι καιρός να τελειώσουμε και το τελευταίο κεφάλαιο, έχοντας μια σύνδεση TCP και μια σύνδεση UDP να ανταγωνίζονται για τον ίδιο πόρο, την χωρητικότητα του δικτύου. Αυτό μάλιστα το θέμα είναι άκρως ενδιαφέρον γιατι θα μας δώσει την δυνατότητα να καταλάβουμε τι περίπου συμβαίνει και με το ελληνικό ADSL.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  flows-05.gif 
Εμφανίσεις:  42 
Μέγεθος:  2,8 KB 
ID: 7275

    Η τοπολογία θα είναι όπως και πριν αλλά θα έχουμε δύο συνδέσεις, μια TCP και μια UDP όπως φαίνεται και απο το παραπάνω σχήμα. Και στα δύο άκρα έχουμε TCP και UDP. Απο το σημείο Α
    έχουμε μια σύνδεση FTP που μπορεί να στέλνει συνεχώς πακέτα, και μια σύνδεση UDP που στέλνει συνεχώς δεδομένα με σταθερό ρυθμό (CBR) 0.95 Mbps. Ολα τα πακέτα, TCP & UDP, έχουν το ίδιο μέγεθος, 1000 bytes.To σημείο Β είναι υποχρεωμένο να κάνει acknowledge τα πακέτα TCP, και τα πακέτα ACK έχουν μέγεθος 40 bytes. H σύνδεση είναι ταχύτητας 2Mbps και δημιουργεί καθυστέρηση 10ms. Το μέγεθος της buffer είναι 20 πακέτα, άρα μπορεί να έχουμε το πολύ 20 πακέτα σε ουρά. Η ουρά υλοποιεί την στρατηγική droptail (FIFO). Οι περισσότεροι routers δουλεύουν με όμοιο τρόπο. Το TCP Reno είναι αυτό που χρησιμοποιείται εδώ.

    Την χρονική στιγμή 0.1 δευτερόλεπτα, αρχίζει η αποστολή πακέτων TCP & UDP και σταματά ακριβώς στα 10 δευτερόλεπτα. Για κάθε δοκιμή, θα μελετήσουμε τις εξής πληροφορίες

    1. Στιγμιαία ροή σε kbps
    2. Συνολική ροή σε kbps
    3. Καθυστέρηση (latency) σε msec
    4. Jitter σε msec
    5. Bytes που μεταφέρθηκαν
    6. Απώλειες.

    Το πρώτο γράφημα είναι η στιγμιαία ταχύτητα σε kbps

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  bw-tcp+udp.png 
Εμφανίσεις:  45 
Μέγεθος:  6,0 KB 
ID: 7276

    Βλέπουμε λοιπον μια παλινδρόμηση της ροής TCP και της ροής UDP. Αυτό προκύπτει απο το ανταγωνισμό τους για τον ίδιο πόρο, την χωρητικότητα δικτύου. Παρόλα αυτά βλέπουμε ότι παίρνουν σχεδόν το μισό η καθε μιά ροή, και αυτό προκύπτει και απο το γεγονός ότι το UDP προσπαθεί να στείλει με σταθερή ταχύτητα 0.95 Mbps και το TCP προσπαθεί να εκμεταλλευτεί πλήρως το υπόλοιπο 1.05Mbp. Αλλά ο ανταγωνισμός είναι αναπόφεκτος. Οταν το TCP κάνει πίσω, το UDP παίρνει το πλεονέκτημα και προσπαθεί να ελέγξει την διαθέσιμη χωρητικότητα και αυτό δημιουργεί τις κορυφές του γραφήματος. Αμέσως βέβαια το TCP προσπαθεί να ελέγξει εαν μπορεί να πάρει επιπλέον bandwidth, αυξάνει το bandwidth που ζητά, και τότε το UDP πέφτει (κοιλάδες του γραφήματος UDP). Αυτός ο κύκλος επαναλαμβάνεται συνεχώς.

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

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  meanbw-tcp+udp.png 
Εμφανίσεις:  42 
Μέγεθος:  4,3 KB 
ID: 7277

    Εδώ φαίνεται πιο καθαρά η απώλεια που έχει το TCP κατα την έναρξη της δοκιμής. Ομως με το πέρασμα του χρόνου βλέπουμε τις δύο γραμμές να προσεγγίζουν η μια την άλλη, και να υποδηλώνεται ότι κάθε σύνδεση θα παίρνει το 50% του καναλιού.

    Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  latency-tcp+udp.png 
Εμφανίσεις:  46 
Μέγεθος:  4,0 KB 
ID: 7278

    Εδώ βλέπουμε επίσης μια παλιδρόμηση του latency, και αυτό οφείλεται στο ότι δεν έχουν σταθερές ταχύτητες οι συνδέσεις TCP & UDP. Μαλιστα είναι χειρότερα απο δυο TCP συνδέσεις ή δύο UDP συνδέσεις που είδαμε σε προηγούμενα κεφάλαια. Και φυσικά περιμένουμε ότι και το jitter δεν θα είναι επίσης καλό, όπως στο παρακάτω γράφημα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  jitter-tcp+udp.png 
Εμφανίσεις:  38 
Μέγεθος:  4,7 KB 
ID: 7279

    Και εδώ φαίνεται μια συμπεριφορά χειρότερη και απο τις δύο tcp συνδέσεις.


    Ας δούμε το συνολικό αριθμό bytes που μεταφέρθηκαν

    ΤCP Kbytes sent: 1150.742188
    UDP Kbytes sent: 1148.437500
    Συνολικά bytes : 2299.180288

    Εαν προσέξετε, για το UDP μεταφέρθηκαν ακριβώς ο ίδιος αριθμός Kbytes όπως και στην περίπτωση δύο UDP συνδέσεων. Φαίνεται λοιπόν ότι έχουμε τη ίδια μετάφορά, όμως έχει χαλάσει πολύ το latency και το jitter.

    Στο τέλος ας δούμε τις απώλειες. Για το TCP έχουμε:

    Σταλθέντα πακέτα: 1158
    Διεγραμμένα πακέτα: 24
    Τελικές απώλειες: 2.072539%

    Για το UDP έχουμε:

    Σταλθέντα πακέτα: 1176
    Διεγραμμένα πακέτα: 0
    Τελικές απώλειες: 0.0%

    Στο UDP έχουμε λοιπόν στείλει τον ίδιο όγκο δεδομένων όπως και με τις δύο συνδέσεις UDP. Ο χαμένος σε πακέτα είναι το TCP αλλά ο μεγάλος χαμένος είναι το UDP, γιατί ενώ δεν έχει χάσει πακέτα, έχει σημαντικό latency & jitter και αυτά επηρεάζουν πολύ τις συνήθεις συνδέσεις udp (συνδέσεις πραγματικού χρόνου όπου οι δύο παραπάνω παράγοντες μειώνουν σημαντικά την ποιότητα). Ετσι χάνεται ουσιαστικά ο λόγος ύπαρξης του UDP....

    [break=Μια σύνδεση TCP και μια σύνδεση UDP (b)]

    2.5.b

    Ας προχωρήσουμε λοιπόν διαφοροποιώντας λίγο το δίκτυο και να δούμε πως συμπεριφέρεται. Εδώ λοιπόν θα κάνουμε το μέγεθος των πακέτων 100 bytes αντί για 1000 bytes. Πάμε λοιπόν κατευθείαν στα γραφήματα.

    Πρώτα απο όλα να δούμε την στιγμιαία ταχύτητα

    [Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  bw-tcp+udp-100bytes.png 
Εμφανίσεις:  50 
Μέγεθος:  3,3 KB 
ID: 7407

    Το μικρότερο μέγεθος πακέτου δημιουργεί σημαντικά μικρότερη παλινδρόμηση. Οι κορυφές και οι κοιλάδες απο το αντίστοιχο προηγούμενο γράφημα είναι πλέον πιο κοντά. Επίσης φαίνεται να είναι πολύ πιο κοντά στο 50% η κατανάλωση bandwidth απο τις δύο αυτές συνδέσεις. Ας δούμε και την συνολική ταχύτητα....

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  meanbw-tcp+udp-100bytes.png 
Εμφανίσεις:  36 
Μέγεθος:  3,4 KB 
ID: 7408

    Βλέπουμε λοιπόν ότι τα πράγματα πάνε πολύ καλύτερα. Η κατανομή της διαθέσιμης ταχύτητας είναι πλέον πιο δίκαια για τις δύο αυτές συνδέσεις. Η σύνδεση UDP παίρνει ακριβώς αυτό που ζητά, δηλαδή 0.95Mbps και η σύνδεση TCP ακριβως το υπόλοιπο. Επίσης αυτό που παρατηρείται είναι ότι δεν έχουμε πλέον την απώλεια ταχύτητας στην έναρξη του TCP όπως είχαμε στην πρώτη περίπτωση με τα πακέτα των 1000 bytes. Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  latency-tcp+udp-100bytes.png 
Εμφανίσεις:  40 
Μέγεθος:  3,6 KB 
ID: 7409

    Εδώ φαίνεται σημαντική βελτίωση. Χρησιμοποιώντας λοιπόν μικρά πακέτα, έχουμε ένα latency 11.5 msec που είναι πολύ καλό, ακόμη και για εφαρμογές πραγματικού χρόνου (όπως VoIP). Και απο το γράφημα συμπερένουμε ότι θα έχουμε και καλλό jitter...

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  jitter-tcp+udp-100bytes.png 
Εμφανίσεις:  46 
Μέγεθος:  3,0 KB 
ID: 7410

    Πάρα πολύ καλό. Οπως βλέπετε, το jitter είναι γύρω στο 0, με κάποιες ελάχιστες εξαιρέσεις, σε τιμές +/- 0.5

    Αρα η χρήση μικρών πακέτων έχει βοηθήσει σημαντικά στην μείωση των καθυστερήσεων.

    Για να δούμε τι γίνεται και με το σύνολο των πακέτων.
    TCP KB sent: 1259.902344
    UDP KB sent: 1148.144531
    TOTAL KB Sent: 2408.046875

    Εαν το συγκρίνουμε με πρίν, θα δούμε ότι στο UDP δεν βελτιώθηκε τίποτε (απο άποψη μεταφερόμενων ΚΒ), αλλά έχει βελτιωθεί το TCP σημαντικα. Εχουμε συνολικά 9,84% περισσότερα ΚΒ απο πριν. Αρα τα μικρά πακέτα βοηθούν να αποφύγουμε το αρχικό επεισόδιο απώλειας πακέτων που επιβάρυνε σημαντικά το TCP.

    Ας δούμε και τις απώλειες. Για το TCP έχουμε:
    Packets sent: 9216
    Packets dropped: 0
    Total losses: 0.000000%

    Για το UDP
    Packets sent: 11757
    Packets dropped: 0
    Total losses: 0.000000%

    Βλέπουμε λοιπον ότι πλέον δεν έχουμε απώλειες. Σαν συμπέρασμα έχουμε ότι μειώνοντας το μέγεθος των πακέτων και εφόσον η σύνδεση επαρκεί (και περισσεύει) για την σύνδεση UDP (και αυτό γιατί το TCP αυτορυθμίζεται) τότε όλα είναι τέλεια. Το UDP παίρνει χωρίς απώλειες και μικρή καθυστέρηση το bandwidth που χρειάζεται και το TCP παίρνει όλο το υπόλοιπο....

    [break=Μια σύνδεση TCP και μια σύνδεση UDP (c)]

    2.5.c

    Για να δούμε τώρα τι θα συμβεί εαν αυξήσουμε το μέγεθος των πακέτων στα 4000 bytes. Πρώτα απο όλα ας δούμε το γράφημα στιγμιαίας ταχύτητας.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  bw-tcp+udp-100bytes.png 
Εμφανίσεις:  50 
Μέγεθος:  3,3 KB 
ID: 7407

    Οπως φαίνεται τα πράγματα δεν πάνε καλά... Υπάρχει ανταγωνισμός για το bandwidth απο τις δύο συνδέσεις. Ας δούμε και την συνολική ταχύτητα...

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  meanbw-tcp+udp-100bytes.png 
Εμφανίσεις:  36 
Μέγεθος:  3,4 KB 
ID: 7408

    Κατευθείαν, με την πρώτη ματιά, φαίνεται ότι έχουμε πλέον απώλειες. Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  latency-tcp+udp-100bytes.png 
Εμφανίσεις:  40 
Μέγεθος:  3,6 KB 
ID: 7409

    Eδώ τα πράγματα έχουν γίνει τραγικά. Εχει φτάσει τα 350 msec. Και βλέπουμε ότι έχει διακυμάνσεις, άρα και το jitter θα είναι υψηλό.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  jitter-tcp+udp-100bytes.png 
Εμφανίσεις:  46 
Μέγεθος:  3,0 KB 
ID: 7410

    Εχουμε 30-50 msec jitter. Φαίνεται πλέον ξεκάθαρα ότι όσο μεγαλώνουν τα πακέτα, latency & jitter ξεφεύγουν πολύ...

    Ας δούμε και πόσα ΚΒ μεταφέρθηκαν. Για TCP έχουμε:
    Packets sent: 334
    Packets dropped: 7
    Total losses: 2.095808%

    Για το UDP έχουμε:
    Packets sent: 294
    Packets dropped: 12
    Total losses: 4.081633%

    Οπως βλέπουμε, το UDP επηρεάστηκε περισσότερο απο το TCP, και φυσικά προς το χειρότερο.

    [break=Μια σύνδεση UDP και μια σύνδεση TCP (d)]

    2.5.d

    Μέχρι τώρα είδαμε περιπτώσεις όπου το κύκλωμα επαρκούσε και πειράζαμε μόνο το μέγεθος πακέτου. Για να δούμε εαν η ταχύτητα κυκλώματος δεν επαρκεί (δηλαδή δημιουργούμε κορεσμό). Εδώ τα πράγματα πλέο γίνονται πραγματικά πολύ ενδιαφέροντα (για εμάς που τρώμε πακέτα!!!) Πως θα αντιδράσει το UDP άραγε; και πως το TCP; Ας δούμε το πρώτο γράφημα με την στιγμιαία ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  bw-tcp+udp-1Mb.png 
Εμφανίσεις:  48 
Μέγεθος:  5,5 KB 
ID: 7416

    Λοιπόν το TCP έχει σημαντικό πρόβλημα. Πολυ απλά δεν μπορεί να λειτουργήσει. Προσπαθεί να πάρει κάτι απο το bandwidth αλλά φυσικά δεν μπορεί. Ας δούμε και την συνολική ταχύτητα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  meanbw-tcp+udp-1Mb.png 
Εμφανίσεις:  52 
Μέγεθος:  4,1 KB 
ID: 7417

    Σε αυτο το γράφημα φαίνεται καλύτερα η αποτυχία του TCP. Βλέπουμε καθαρά, ότι δεν έχει περιθωριο απο το bandwidth, και τελικά περιορίζεται σε ένα ελάχιστο κοντά στα 100 Kbps. Λογικά το περισσευούμενο bandwidth δεν ειναι 100 kbps αλλα πολύ λιγότερο (μην ξεχνάμε ότι το UDP θέλει 0.95Mbps). Αλλα με τον ανταγωνισμό που κάνει το TCP με το UDP, "κλέβει" λίγο απο το UDP (θα το δούμε και παρακάτω στις απώλειες) και έτσι φτάνει στα 100 περίπου Kbps, αλλά κ αι αυτό το "κλέψιμο" σίγουρα θα δημιουργεί πρόβλημα και στο UDP. Ας δούμε και το latecy


    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  latency-tcp+udp-1Mb.png 
Εμφανίσεις:  52 
Μέγεθος:  3,6 KB 
ID: 7418

    Βλέπουμε λοιπόν ότι και το TCP αλλά και το UDP έχουν επηρεαστεί σημαντικά, και έχουμε πλέον latency 200-240 msec. Οι τιμές αυτές δεν είναι καλές για εφαρμογές πραγματικού χρόνου (μην ξεχνάμε ότι μιλάμε για ένα απευθείας κύκλωμα, φανταστείτε το σε ιντερνετικές διαστάσεις πόσο θα πήγαινε το latency). To TCP έχει επηρεαστεί ακόμη περισσότερο, και έχουμε περιπτώσεις καθυστέρησης κοντά στα 4 δευτερόλεπτα. Ας δούμε και το jitter.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  jitter-tcp+udp-1Mb.png 
Εμφανίσεις:  30 
Μέγεθος:  3,7 KB 
ID: 7419

    Εχουμε λοιπόν κάποιες διαφοροποιήσεις που φτάνουν και 80 msec.

    Ας δούμε πόσα ΚΒ μεταφέρθηκαν. Απο το TCP έχουμε:
    KB sent: 92.460938

    Πολύ άσχημα. Το TCP έχει περίπου το 10% του διαθέσιμου bandwidth. Για το UDP:
    KB sent: 1133.789062

    Βλέπουμε λοιπόν ότι το UDP έχει μικρή διαφορά απο το προηγούμενο καλό παράδειγμα και συγκεκριμένα έχει μόνο 1.31% απώλεια.

    Ας δούμε και τις απώλειες. Για το TCP έχουμε.
    Packets sent: 120
    Packets dropped: 28
    Τotal losses: 23.333333%

    Και για το UDP αντίστοιχα
    Packets sent: 1176
    Packets dropped: 15
    Total losses: 1.275510%

    Εχουμε λοιπόν μόλις 1.27% απώλεια για το UDP, αλλά παρόλα αυτά, εαν σκεφτούμε ότι βασικά το UDP χρησιμοποιείται σε εφαρμογές πραγματικού χρόνου, latency & jitter έχου αυξηθεί τόσο, ώστε και το UDP να είναι πλέον και αυτό άχρηστο... Οσο για το TCP, είναι ο μεγάλος χαμένος. Βάσει του πρωτοκόλλου αυτού, που προσπαθεί να είναι καλός παίκτης στα δίκτυα, και να αναπροσαρμόζεται, περιορίζεται σε ένα πολύ μικρό ποσοστό του bandwidth που περισσεύει και φυσικά η διαφορά με τις άλλες περιπτώσεις είναι κυριολεκτικά δραματική.

    Συμπεράσματα

    Αυτό δείχνει ότι προκειμένου να παίζει καλά και το ένα πρωτόκολλο και το άλλο, πρέπει το διαθέσιμο bandwidth πρώτα απο όλα να επαρκεί για τo UDP αλλά να υπάρχει επίσης αρκετό για το TCP επίσης. Αυτό, αν το σκεφτούμε λίγο, δείχνει επίσης γιατί "τρώμε πακέτα" απο τον ΟΤΕ. Εαν λοιπόν το δίκτυο ήταν fairuse για οποιοδήποτε πρωτόκολλο, τότε η χρήση udp, σε γραμμές τόσο μικρές (adsl384) θα τις έκανε άχρηστες, τόσο για VoIP αλλά και για TCP (δηλαδή web surfing, email κλπ). Και αυτό γιατί με βάση το contention ratio (1/20) ουσιαστικά για τον καθένα αντιστοιχεί 19.2 Κbps πραγματικά. Για VoIP χρειαζόμαστε τουλάχιστον 40Kbps. Αυτό σημαίνει με απλά λόγια ότι εαν ένας στους δύο έχει VoIP, τότε δεν θα παίζει τίποτα άλλο και για κανένα (αν βάλουμε και τα υπόλοιπα, DNS, ARP κλπ τότε μπορεί να φτάσουμε και ένας στους τρείς να παίζει ταυτόχρονα VoIP και δεν θα παίζει τίποτα άλλο και για κανέναν άλλο χρήστη). Και φυσικά για να έχουμε VoIP σωστό θα πρέπει το bandwidth που μας αναλογεί με βάσει το contention ratio να φτάνει και να περισσεύει (πχ 1024Kbps με 1/20 μας δίνει 50Κbps που είναι οριακό για να παίζει καλό VoIP - και με καλό codec). Αρα για πραγματικά ευρυζωνικά θα πρέπει να μιλάμε για πάνω απο 1024Kbps!!! (ή πολύ μικρότερο επίσης contention ratio )

    Παρακάτω θα δούμε πως επηρεάζει και το μέγεθος της ουράς την ποιότητα της επικοινωνίας.

    [break=Μια σύνδεση UDP και μια σύνδεση TCP (e)]

    2.5.e

    Τώρα θα προχωρήσουμε, όπως το αρχικό σενάριο (2.5.α) αλλά αντί για ουρά (buffer) που να χωρά 20 πακέτα, θα βάλουμε μια ουρά μεγέθους 50 πακέτων. Η στιγμιαία ταχύτητα έχει το παρακάτω γράφημα.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  bw-tcp+udp-overbuf.png 
Εμφανίσεις:  45 
Μέγεθος:  4,2 KB 
ID: 7426

    Βλέπουμε λοιπόν στο γράφημα αυτό, και συγκρίνοντας το με το αντίστοιχο του 2.5.α, ότι η αύξηση του μεγέθους της buffer έκανε μια εξομάλυνση. Οι καμπύλες είναι πιο ομαλές και η παλινδρόμηση σημαντικά μικρότερη. Η συνολική ταχύτητα

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  meanbw-tcp+udp-overbuf.png 
Εμφανίσεις:  33 
Μέγεθος:  3,7 KB 
ID: 7427

    Βλέπουμε και εδώ πόσο βοηθάει στο TCP η χρήση μεγάλων buffers. Πάει πλέον η αρχική βουτιά που έκανε το TCP και βλέπουμε μια σχεδόν ομαλή ροή. Ας δούμε και το latency

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  latency-tcp+udp-overbuf.png 
Εμφανίσεις:  38 
Μέγεθος:  4,1 KB 
ID: 7428

    Βλέπουμε λοιπόν ότι έχουμε λίγο μεγαλύτερο latency (και αυτό γιατί; μα έχουμε περισσότερα πακέτα στην ουρά, άρα κάνουν συνολικά περισσότερο χρόνο μέχρι να φτάσουν απέναντι). Ομως βλέπουμε ότι είναι σταθερό, χωρίς σκαμπανεβάσματα σταθερά στα 150 περίπου msec.

    Τωρα για να δούμε τι συμβαίνει με τις buffers. Οταν είχαμε buffer χωρητικότητας μόνο 20 πακέτων, τότε το γράφημα παρακάτω μας δειχνει πόσα πακέτα έχει η buffer κάθε χρονική στιγμή απο κάθε σύνδεση (υπόψη ότι το άρθροισμα δεν μπορεί να είναι παραπάνω απο 20, εαν έλθει πακέτο πριν αδειάσει απο την buffer σχετικός χώρος, τότε το πακέτο διαγράφεται, και μετά αυτό φαίνεται ως απώλειες).

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  queue-tcp+udp.png 
Εμφανίσεις:  37 
Μέγεθος:  6,6 KB 
ID: 7430

    Φαίνεται λοιπόν ότι στις κορυφές, φτάνουμε στα όρια της buffer. Ας το δούμε και συνολικά, δηλαδή ένα γράφημα που να έχει για όλες τις συνδέσεις (tcp & udp) τον αριθμο πακέτων στην buffer.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  totalqueue-tcp+udp.png 
Εμφανίσεις:  31 
Μέγεθος:  5,9 KB 
ID: 7432

    Φαίνεται λοιπόν ξεκάθαρα ότι στις κορυφές φτάνουμε στα όρια της buffer. Ας δούμε λοιπόν τα ίδια , αλλά με buffer μεγέθους 50 πακέτων. Εχουμε λοιπόν.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  queue-tcp+udp-overbuf.png 
Εμφανίσεις:  36 
Μέγεθος:  4,1 KB 
ID: 7431

    Βλέπουμε λοιπόν ότι έχουμε μια ομαλοποίηση της ζήτησης στην Buffer. Φαίνεται απο το γράφημα αυτό, ότι "πιάνουμε" παραπάνω απο 20 πακέτα κάθε χρονική στιγμή. Ας το δούμε και συνολικά.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  totalqueue-tcp+udp-overbuf.png 
Εμφανίσεις:  39 
Μέγεθος:  3,6 KB 
ID: 7433

    Είμαστε γύρω στα 33 πακέτα. Αρα λοιπόν η buffer των 20 πακέτων δεν ήταν αρκετή, και φυσικά δημιουργούσε απώλειες και παλινδρομήσεις, που αυτά στην συνέχεια δημιουργούσαν, τι άλλο , jitter! Ομως αφού η buffer είναι πλέον μεγαλύτερη, λογικά πλέον έχουμε και μεγαλύτερο latency. Ας δούμε και το γράφημα του jitter.

    Πατήστε στην εικόνα για να τη δείτε σε μεγέθυνση. 

Όνομα:  jitter-tcp+udp-overbuf.png 
Εμφανίσεις:  43 
Μέγεθος:  3,2 KB 
ID: 7429

    Οπως το περιμέναμε. Το jitter είναι σχεδόν μηδενικό. (παίζει λίγο +/- 4msec). Ας δούμε και το συνολικο αριθμό ΚΒ που μεταφέρθηκαν.
    TCP KB sent: 1298.007812
    UDP KB sent: 1148.437500
    Βλέπουμε λοιπόν ότι έχουμε 13% περισσότερο στο TCP απο ότι όταν είχαμε buffer των 20 πακέτων. Για το UDP είναι το ίδιο. Αρα το TCP ευνοείται με την χρήση μεγάλων buffers και αξιοποιεί καλύτερα το διαθέσιμο bandwidth (κάποιοι λέγανε για μεγάλους buffers που έχει ο ΟΤΕ )

    Ας δούμε και τις απώλειες. Για το TCP έχουμε

    Packets sent: 1279
    Packets dropped: 0
    Total losses: 0.000000%

    και για το udp

    Packets sent: 1176
    Packets dropped: 0
    Total losses: 0.000000%

    Απώλειες μηδέν !!!! Θα δούμε στην συνέχεια τι γίνεται με μικρή buffer και θα βγάλουμε και μερικά συμπεράσματα απο αυτό.
    Attached Files Attached Files
    Τελευταία επεξεργασία από το μέλος anon : 08-06-06 στις 08:36.

  2. #2
    Εγγραφή
    09-12-2004
    Περιοχή
    Μπροστά από το πληκτρολόγιο και το δάκτυλο στο ποντίκι
    Ηλικία
    51
    Μηνύματα
    4.616
    Downloads
    5
    Uploads
    0
    Τύπος
    ADSL OTE
    Ταχύτητα
    2048/256
    ISP
    OTEnet
    DSLAM
    ΟΤΕ - ΧΟΛΑΡΓΟΣ
    Router
    Speedtouch 510v4
    SNR / Attn
    19,5(dB) / 23(dB)
    Πολύ καλή προσπάθεια μπράβο

  3. #3
    Εγγραφή
    20-03-2003
    Περιοχή
    Στη μόνη πόλη που γράφεται με 2 'σ' και προφέρεται με 2 'λ'
    Ηλικία
    48
    Μηνύματα
    21.417
    Downloads
    25
    Uploads
    2
    Τύπος
    ADSL2+
    Ταχύτητα
    11000/1023
    ISP
    ΟΤΕ Conn-x
    DSLAM
    ΟΤΕ - ΡΟΣΤΑΝ
    Router
    Netgear DGN2000
    SNR / Attn
    4(dB) / 30.5(dB)
    Path Level
    Fastpath
    Θέλουμε κι άλλο, κι άλλο, κι άλλο
    Άσε τη δουλειά και πιάσε τη μετάφραση/πληκτρολόγηση
    Όσο πιο βαθιά βάζουν το χέρι οι εταίροι στις τσέπες μας, τόσο πιο κοντά φθάνουν στα @@ μας

  4. #4
    Εγγραφή
    17-03-2003
    Περιοχή
    Ηράκλειο Κρήτης
    Μηνύματα
    2.283
    Downloads
    6
    Uploads
    0
    Ταχύτητα
    11050/648
    ISP
    COSMOTE
    Router
    OTE Oxygen Multigateway
    Ξεκινάω την ερώτηση, κάντε κάποιος την απάντηση:

    Τι είναι αυτό το QoS, τι κάνει και γιατί μας ενδιαφέρει;
    Intel i7 Skylake, Nvidia GTX1080Ti - Arch Linux/Windows 10
    Lenovo Thinkpad T470s - Ubuntu 19.04
    iMac G5 - Leaky MB capacitors

  5. #5
    Εγγραφή
    20-03-2003
    Περιοχή
    Στη μόνη πόλη που γράφεται με 2 'σ' και προφέρεται με 2 'λ'
    Ηλικία
    48
    Μηνύματα
    21.417
    Downloads
    25
    Uploads
    2
    Τύπος
    ADSL2+
    Ταχύτητα
    11000/1023
    ISP
    ΟΤΕ Conn-x
    DSLAM
    ΟΤΕ - ΡΟΣΤΑΝ
    Router
    Netgear DGN2000
    SNR / Attn
    4(dB) / 30.5(dB)
    Path Level
    Fastpath
    QoS=Quality of Service= Ποιότητα της υπηρεσίας.

    Στα δίκτυα υπολογιστών είναι το μεγάλο κεφάλαιο του πως μπορείς να διαχειριστείς καλύτερα τον πιο "στρυφνό" (δεν μπορώ να σκεφτώ καλύτερη λέξη) πόρο που έχεις δηλαδή το φυσικό μέσο επικοινωνίας μεταξύ των υπολογιστών.

    Είτε σε περιβάλλον τοπικού δίκτυου, είτε ακόμη περισσότερο σε περιβάλλον Διαδικτύου, το πρόβλημα είναι πάντα ότι η ταχύτητα διασύνδεσης είναι χαμηλότερη των δυνατοτήτων των Η/Υ και φυσικά της υπομονής μας.
    Οπότε το QoS έρχεται να εξασφαλίσει τις προτεραιότητες που θα δίνονται σε αυτή την επικοινωνία, έτσι ώστε οι πραγματικά σπουδαίες επικοινωνίες να εξυπηρετούνται πριν τις δευτερεύουσες.

    Προφανώς αυτή είναι μια quick'n'dirty απάντηση. Το QoS είναι ΠΟΛΥ μεγάλο θέμα
    Όσο πιο βαθιά βάζουν το χέρι οι εταίροι στις τσέπες μας, τόσο πιο κοντά φθάνουν στα @@ μας

  6. #6
    Εγγραφή
    11-07-2005
    Περιοχή
    Λουξεμβούργο
    Ηλικία
    53
    Μηνύματα
    10.348
    Downloads
    6
    Uploads
    1
    Τύπος
    FTTH
    Ταχύτητα
    500Μ Download/260M Uploa
    ISP
    Διάφοροι. Ολο
    Router
    Fritzbox!7490
    Μου κάνει εντύπωση που δεν βλέπω καθόλου feedback. Ή είμαι φοβερός (βασικα ο Leonardo) ώστε όλα να είναι τόσο εύκολα κατανοητά, και να μην υπάρχουν απορίες κλπ ή μάλλον τσάμπα γράφω

  7. #7
    Το avatar του μέλους chatasos
    chatasos Guest
    Δεν μπορείς να πείσεις εύκολα τον κόσμο ότι συγκεκριμένες συμπεριφορές στα δίκτυα είναι αναμενόμενες λόγω της φύσης τους.

  8. #8
    Εγγραφή
    20-03-2003
    Περιοχή
    Στη μόνη πόλη που γράφεται με 2 'σ' και προφέρεται με 2 'λ'
    Ηλικία
    48
    Μηνύματα
    21.417
    Downloads
    25
    Uploads
    2
    Τύπος
    ADSL2+
    Ταχύτητα
    11000/1023
    ISP
    ΟΤΕ Conn-x
    DSLAM
    ΟΤΕ - ΡΟΣΤΑΝ
    Router
    Netgear DGN2000
    SNR / Attn
    4(dB) / 30.5(dB)
    Path Level
    Fastpath
    Sorry βρε anon... 'Ηθελα να σε χειροκροτήσω και σήμερα για να σου ανεβάσω το ηθικό αλλά δεν πρόλαβα!

    Σκέψου όμως τι προσφορά δίνεις σε όλους εμάς που απαντάμε τεχνικές ερωτήσεις:
    Ερ. "Το ping μου είναι ψηλό, γιατί;"
    Απ. "Διάβασε το υπόμνημα για το QoS"
    ...

    Ερ. "Το μουλάρι κατεβάζει με 20KB/s, γιατί;"
    Απ. "Διάβασε το υπόμνημα για το QoS"
    ...

    Ερ. "Οι σελίδες αργούν να ανοίξουν, γιατί;"
    Απ. "Διάβασε το υπόμνημα για το QoS"
    ...

    Και ΤΟΣΑ, ΤΟΣΑ άλλα!

    Στοιχηματίζω ότι το 99% αυτών που θα "διαβάσουν" το υπόμνημα... δε θα ξανατολμήσουν να ρωτήσουν
    Όσο πιο βαθιά βάζουν το χέρι οι εταίροι στις τσέπες μας, τόσο πιο κοντά φθάνουν στα @@ μας

  9. #9
    Εγγραφή
    16-07-2004
    Περιοχή
    Θεσσαλονίκη
    Ηλικία
    51
    Μηνύματα
    1.689
    Downloads
    0
    Uploads
    0
    Τύπος
    PSTN
    Ταχύτητα
    20480/1024
    ISP
    ΟΤΕ Conn-x
    Router
    ZTE w300i
    Path Level
    Interleaved
    Συνέχισε ακάθεκτος.
    Δεν μας τρομάζει η πολλή θεωρία.

    Εμένα το μόνο που με προβληματίζει είναι να βρώ κάποια φόρμουλα από όλα αυτά
    που μοιράζεσαι μαζί μας ώστε να χειριστώ το latency στο speedtouch ipqos με το
    οποίο που και που καταπιάνομαι...
    Όλα τα παιχνίδια android που έχω φτιάξει περιγράφονται και
    κατεβαίνουν από εδώ: https://sites.google.com/site/carbonpeoplegames/

  10. #10
    Εγγραφή
    11-07-2005
    Περιοχή
    Λουξεμβούργο
    Ηλικία
    53
    Μηνύματα
    10.348
    Downloads
    6
    Uploads
    1
    Τύπος
    FTTH
    Ταχύτητα
    500Μ Download/260M Uploa
    ISP
    Διάφοροι. Ολο
    Router
    Fritzbox!7490
    Παράθεση Αρχικό μήνυμα από zardoz Εμφάνιση μηνυμάτων
    Συνέχισε ακάθεκτος.
    Δεν μας τρομάζει η πολλή θεωρία.

    Εμένα το μόνο που με προβληματίζει είναι να βρώ κάποια φόρμουλα από όλα αυτά
    που μοιράζεσαι μαζί μας ώστε να χειριστώ το latency στο speedtouch ipqos με το
    οποίο που και που καταπιάνομαι...
    Ακόμη έχει αρκετή θεωρία, αλλά το latency, απο την μεριά σου τουλάχιστον, μπορείς να το επηρεάζεις στα εξερχόμενα πακέτα. Στα εισερχόμενα, έχεις μικρή δυνατότητα επηρεασμού. Οπότε μια πολύ απλοική εξήγηση - χειρισμός, είναι να μην έχεις μπουκωμένη γραμμή (στην έξοδό σου) αλλά και στην είσοδο επίσης (αυτό είναι πιο δύσκολο να γίνει). Για περισσότερη ακρίβεια θα πρέπει να έχεις την δυνατότητα να ορίσεις πολιτικές, δηλαδή κανόνες, με ποιά προτεραιτότητα - ταχύτητα και τι κατάληψη bandwidth θα κάνουν στην γραμμή σου τα διάφορα connections, ανάλογα εαν είναι tcp, udp και παέι λέγοντας, και μάλιστα σε επίπεδο εφαρμογής πχ udp/rtp πόρτες τάδε έως τάδε από όπου περνάει η φωνή (VoIP). Δεν ξέρω εαν το speedtouch έχει τέτοιες δυνατότητες, έχω δουλέψει μόνο cisco και linux σε αυτά τα πράγματα.

  11. #11
    Εγγραφή
    01-11-2004
    Ηλικία
    33
    Μηνύματα
    950
    Downloads
    8
    Uploads
    0
    Τύπος
    ADSL2+ Forthnet Full
    Ταχύτητα
    12288/1024
    ISP
    Forthnet
    DSLAM
    Forthnet - ΙΛΙΣΟΣ
    Router
    Siemens SL2-141
    SNR / Attn
    6(dB) / 38(dB)
    Παράθεση Αρχικό μήνυμα από anon Εμφάνιση μηνυμάτων
    Δεν ξέρω εαν το speedtouch έχει τέτοιες δυνατότητες, έχω δουλέψει μόνο cisco και linux σε αυτά τα πράγματα.
    To 9105 έχει linux, κάτι θα μπορέσουμε να κάνουμε με αυτό έτσι;

    Δεν πρόλαβα να το διαβάσω όλο, αλλά μου φαίνεται εξαιρετικό. Εύγε!

  12. #12
    Εγγραφή
    11-07-2005
    Περιοχή
    Λουξεμβούργο
    Ηλικία
    53
    Μηνύματα
    10.348
    Downloads
    6
    Uploads
    1
    Τύπος
    FTTH
    Ταχύτητα
    500Μ Download/260M Uploa
    ISP
    Διάφοροι. Ολο
    Router
    Fritzbox!7490
    Παράθεση Αρχικό μήνυμα από Legend Εμφάνιση μηνυμάτων
    To 9105 έχει linux, κάτι θα μπορέσουμε να κάνουμε με αυτό έτσι;
    εχει iptables / tc traffic shaper?

  13. #13
    Εγγραφή
    01-11-2004
    Ηλικία
    33
    Μηνύματα
    950
    Downloads
    8
    Uploads
    0
    Τύπος
    ADSL2+ Forthnet Full
    Ταχύτητα
    12288/1024
    ISP
    Forthnet
    DSLAM
    Forthnet - ΙΛΙΣΟΣ
    Router
    Siemens SL2-141
    SNR / Attn
    6(dB) / 38(dB)
    Παράθεση Αρχικό μήνυμα από anon Εμφάνιση μηνυμάτων
    εχει iptables / tc traffic shaper?
    Έχει iptables v1.2.7.a σε Busybox (δεν γνωρίζω έκδοση)...

  14. #14
    Εγγραφή
    01-07-2003
    Περιοχή
    Θεσσαλλλλονίκη
    Μηνύματα
    65.454
    Downloads
    39
    Uploads
    14
    Τύπος
    Cable
    Ταχύτητα
    200000/200000
    ISP
    HCN - OTE
    DSLAM
    ΟΤΕ - ΡΟΣΤΑΝ
    Router
    asus,vigor
    SNR / Attn
    11.5(dB) / 30.5(dB)
    Path Level
    Interleaved
    Μπράβο είπα;

    Δεν είπα, και ζητώ συγνώμη!!


    anon!!
    επιχειρήματα 4ου τύπου

  15. #15
    Εγγραφή
    11-07-2005
    Περιοχή
    Λουξεμβούργο
    Ηλικία
    53
    Μηνύματα
    10.348
    Downloads
    6
    Uploads
    1
    Τύπος
    FTTH
    Ταχύτητα
    500Μ Download/260M Uploa
    ISP
    Διάφοροι. Ολο
    Router
    Fritzbox!7490

Σελ. 1 από 5 123 ... ΤελευταίαΤελευταία

Παρόμοια Θέματα

  1. Τι ειναι το Atm Oam και πως διορθωνεται ?
    Από antonisgprs στο φόρουμ Nova
    Μηνύματα: 8
    Τελευταίο Μήνυμα: 22-11-10, 16:16
  2. τι ειναι τα ports και πως λειτουργουν?
    Από STASA στο φόρουμ BitTorrent
    Μηνύματα: 1
    Τελευταίο Μήνυμα: 29-06-08, 12:00
  3. Μηνύματα: 2
    Τελευταίο Μήνυμα: 22-01-07, 13:47
  4. Προορισμός Διακοπών Και Πως Να Είναι Αυτές!!!
    Από NeKaKoS στο φόρουμ The Meeting point
    Μηνύματα: 56
    Τελευταίο Μήνυμα: 01-06-06, 13:56
  5. Τι ειναι ο DMZ και πως τον απενεργοποιω???
    Από fsv_quality στο φόρουμ Alcatel Thomson ADSL modems και routers
    Μηνύματα: 0
    Τελευταίο Μήνυμα: 01-12-05, 09:52

Tags για αυτό το Θέμα

Bookmarks

Bookmarks

Δικαιώματα - Επιλογές

  • Δεν μπορείτε να δημοσιεύσετε νέα θέματα
  • Δεν μπορείτε να δημοσιεύσετε νέα μηνύματα
  • Δεν μπορείτε να αναρτήσετε συνημμένα
  • Δεν μπορείτε να επεξεργαστείτε τα μηνύματα σας
  •  
  • Τα BB code είναι σε λειτουργία
  • Τα Smilies είναι σε λειτουργία
  • Το [IMG] είναι σε λειτουργία
  • Το [VIDEO] είναι σε λειτουργία
  • Το HTML είναι εκτός λειτουργίας