Σελ. 1 από 2 12 ΤελευταίαΤελευταία
Εμφάνιση 1-15 από 16
  1. #1
    Εγγραφή
    05-10-2012
    Ηλικία
    41
    Μηνύματα
    44
    Downloads
    0
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    50633/5495
    ISP
    ΟΤΕ Conn-x
    DSLAM
    ΟΤΕ - ΜΥΤΙΛΗΝΙΟΙ
    Router
    Speedport Plus+ NetdumaR1
    SNR / Attn
    9.7(dB) / 16.0(dB)
    Path Level
    Fastpath
    Τι κάνουν τα script :

    Εξαλείφουν το φαινόμενο bufferbloat και τις αρνητικές επιπτώσεις του.
    Εφαρμόζει τον αλγόριθμο Cake στο upload και στο download σας.


    Εξαλείφει την συμφόρηση στο δίκτυο σας περιορίζοντας το εύρος στο 70% του συνολικού εύρους ζώνης που έχετε διαθέσιμο. (η τιμή μπορεί να αλλάξει πχ 80%,85% κτλ.)


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

    Προαπαιτούμενα:

    Βεβαιωθείτε ότι έχετε αναβαθμίσει το Edgerouter X στην τελευταία διαθέσιμη έκδοση.
    Αυτή την ώρα που φτιάχτηκε ο οδηγός η τελευταία έκδοση είναι η 1.10.7


    Θα χρειαστεί την προσοχή σας για τα επόμενα 30 λεπτά περίπου.

    Απενεργοποιήστε όλες τις λειτουργίες QOS μέσα από το Edgerouter X.

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

    Το EdgeRouter X έχει περιορισμένες δυνατότητες επεξεργασίας δεδομένων και κάθε περιττή κίνηση δεδομένων να αποφεύγεται κατά τη διάρκεια της εγκατάστασης.

    Δημιουργήστε ένα backup από τις ρυθμίσεις του Edgerouter X πριν συνεχίσετε.

    Εργαλεία που θα χρησιμοποιήσουμε:

    Έναν browser ...εγώ χρησιμοποιώ τον Vivaldi...εσείς επιλέξτε όποιον θέλετε πχ Chrome.
    WinScp : Την τελευταία έκδοση μπορείτε να την κατεβάσετε από εδώ.

    Οδηγός:

    Πρώτα ανοίξτε τον browser και στην διεύθυνση γράψτε “www.dslreports.com/speedtest” και κάντε ένα τεστ θα μοιάζει κάπως έτσι. (η φωτογραφία είναι τυχαία απλά για να δείτε πως είναι)







    Ανοίξτε το γραφικό περιβάλλον (GUI) του Edgerouter X στον browser σας.
    Θα χρειαστεί να γράψετε 192.168.1.1 προκειμένου να έχετε πρόσβαση.
    Βεβαιωθείτε ότι είναι στην τελευταία έκδοση όπως στην παρακάτω φωτό.



    Αν είστε στην τελευταία έκδοση συνεχίστε....αν όχι πρέπει πρώτα να αναβαθμίσετε το Edgerouter X.


    Κάντε κλίκ στο “system”...κατεβείτε λίγο παρακάτω μέχρι το “Configuration Management” και κάντε κλίκ στο “Download” .Έτσι κάνετε backup τις ρυθμίσεις σε περίπτωση που θέλετε να τις επαναφέρετε.





    Κατεβείτε ακόμη παρακάτω στην ίδια οθόνη έως ότου φτάσετε στο “Management Settings”...
    Βεβαιωθείτε ότι στο SSH Server “Enable” έχει τικ και στο “port” 22 μετά πατήστε “Save”.



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

    Εκτελέστε το WinSCP ...
    Αφού ανοίξει θα χρειαστεί να βάλετε τους κωδικούς σας.

    Στο step 1 βάζετε το username που έχετε...
    Στο step 2 βάζετε τον κωδικό σας ..
    Στο step 3 πατήστε για να κάνετε login.



    Αυτή την εικόνα θα δείτε αφού κάνετε login....
    Στο step 1 που δείχνει η φωτό αντιγράφετε ολόκληρο τον φάκελο “config” στο root κατάλογο.



    Αφού έχετε αντιγράψει τον φάκελο “config” από τον υπολογιστή σας πάνω από τον κατάλογο “config” του ρούτερ σας πηγαίνετε στο /config/scripts/post-config.d/




    Κάνετε δεξί κλίκ στο αρχείο installCake.sh και επιλέγετε “properties



    Θα δείτε το παρακάτω ....



    Στο “Octal” γράφετε 0777 και πατάτε ‘ΟΚ



    Πατάτε στο “Open terminal” ...



    Στο νέο παράθυρο που άνοιξε ..


    Στο step1 “Enter command” γράψτε ...
    sudo vbash installCake.sh


    Στο step 2 πατήστε στο “Execute



    Αφού περάσατε την προηγούμενη εντολή ένα παράθυρο λάθους θα ανοίξει (error).
    Είναι απόλυτα φυσιολογικό και δεν χρειάζεται να ανησυχείτε.Το μήνυμα δείχνει την κατάσταση από το προηγούμενο TC (modified Traffic Control) και τα module του CAKE (SQM).
    Αυτά τα module είναι πλέον ενεργοποιημένα στο Edgerouter X.



    Τώρα μπορείτε να διαγράψετε το “installCake.sh”....δεν το χρειαζόμαστε πλέον.
    Step 1 ...δεξί κλίκ στο αρχείο “installCake.sh
    Step2...πατάτε στο “Delete



    Κάντε μια επανεκκίνηση στο ρούτερ....κλίκ στο “Open terminal” ξανά και γράφετε sudo reboot όπως δείχνει στο step 1 παρακάτω και πατήστε στο “Execute



    Μετά την επανεκκίνηση, περιμένετε περίπου 5 λεπτά μέχρι να αρχίσετε να χρησιμοποιείτε το ρούτερ σας για σελίδες / downloads / gaming. Η βελτιστοποίηση της γραμμής αρχίζει 3 λεπτά μετά την ολοκλήρωση της διαδικασίας εκκίνησης του ρούτερ. Στη συνέχεια εκτελείται ένα speedtest, υπολογίζει το 70% για το download και για το upload, εφαρμόζει τον αλγόριθμο CAKE για την διόρθωση του bufferbloat και δημιουργεί ένα χρονοπρογραμματιστή για να ξανα-
    βελτιστοποιήσει την γραμμή σας ανά μια ώρα, επαναλαμβάνοντας τα προηγούμενα βήματα.


    Να τονίσω ότι ακόμα και αν παίζουμε εκείνη την ώρα ΔΕΝ χάνουμε την σύνδεση μας πχ στο ps4 να μας κάνει sign out..απλά για κάποια δευτερόλεπτα ίσως να δούμε ελάχιστο “lag” σαν να είμαστε σε κάποιο χάλια lobby...Δεν νομίζω να πειράζει αυτό..τις περισσότερες φορές δεν θα το προσέξετε καν.


    Αν ξανά κάνουμε τεστ θα είναι κάπως έτσι...



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








    Επειδή τα script ήταν για cable VDSL2 με λάθος παραμέτρους στο CAKE για τους ελληνικούς παρόχους,παρακάτω ακολουθούν τα script τα οποία θα αντικαταστήσετε στον φάκελο “config” ΠΡΙΝ τα αντιγράψετε στο ρούτερ.

    Έχουν τροποποιηθεί από εμένα για τις δικές μας γραμμές.

    Στον φάκελο CAKE θα δείτε 2 υποφακέλους ο ένας λέγεται ADSL και ο άλλος VDSL ανάλογα τον τύπο της σύνδεσης που έχετε θα αντικαταστήσετε το αρχείο “CakeDeBloat.sh” που βρίσκεται στον φάκελο “config” με ένα από τα παρακάτω.


    Λοιπόν στον φάκελο ADSL έχουμε:

    pppoa-vcmux Εάν η σύνδεση σας είναι τέτοιου τύπου.


    pppoa-llc Εάν η σύνδεση σας είναι τέτοιου τύπου.






    pppoe-vcmux Εάν η σύνδεση σας είναι τέτοιου τύπου.


    pppoe-llcsnap Εάν η σύνδεση σας είναι τέτοιου τύπου. (Για τους περισσότερους χρήστες)



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


    Στον φάκελο VDSL έχουμε:

    pppoe-ptm Εάν η σύνδεση σας είναι τέτοιου τύπου.

    Εάν χρησιμοποιείται πχ. Το ρούτερ του ΟΤΕ σε passthrough και έχετε το ρούτερ σας να κάνει δεύτερη κλήση pppoe θα χρησιμοποιήσετε το παρακάτω.


    Να ευχαριστήσω τον Lochnair (εγκατάσταση CAKE),τον Sivel (speedtest.py) και τον KayOneX24 (εγκατάσταση,προγραμματισμός).
    Τελευταία επεξεργασία από το μέλος Knomax : 27-10-18 στις 11:02.

  2. #2
    Εγγραφή
    28-03-2006
    Περιοχή
    KV G434
    Ηλικία
    49
    Μηνύματα
    42.180
    Downloads
    23
    Uploads
    0
    Τύπος
    FTTH
    Ταχύτητα
    310/31
    ISP
    Cosmote
    DSLAM
    ΟΤΕ - ΕΡΜΟΥ
    Router
    RB4011iGS+5 ONT: G-010G-R
    Πολύ καλή προσπάθεια αλλά έχω κάποιες παρατηρήσεις:

    1. Το συγκεκριμένο τεστ δεν είναι αξιόπιστο.
    Μπορείς να το επαναλάβεις αρκετές φορές και να σου δώσεις διαφορετικές ενδείξεις για το bufferbloat.
    2. Στο QoS δεν χρειάζεται να να δίνεις προτεραιότητες στο dw.
    Μόνο στο up όπου έχεις συμφόρηση.
    Στο dw δεν μπορείς να έχεις ποτέ συμφόρηση παρά μόνο από λάθος εγκατάσταση.
    3. Το να τρέχεις σε schedule ένα speedtest δεν το βρίσκω σωστό.
    Θα μπορούσες ίσως να ελέγξεις με άλλον τρόπο την συμφόρηση στο δίκτυό σου.
    Ασχολούμαι με ΜΤ και δεν έχω χρησιμοποιήσει Edgerouter οπότε δεν μπορώ να σου πω αν μπορεί να το κάνει ή όχι.
    4. Αυτό που κάνεις είναι στην ουσία bw limit σε καταστάσεις συμφόρησης.
    Αλλά κόβεις πολύ πράμα από default.
    Συνήθως κρατάμε 85% για adsl και 90% της πραγματικής για vdsl.
    5. Ένας τρόπος για να αποφυγής το μποτιλιάρισμα είναι το bw limit.
    Στην ουσία ο εύκολος τρόπος (ποιο γρήγορα αποτελεσματικός) αλλά χάνεις πολλά (κυριότερο το line utilization).
    Ο άλλος, ο δύσκολος τρόπος, είναι να ορίσεις προτεραιότητες χωρίς κανέναν περιορισμό στο bw απλά επιλέγοντας την κατάλληλη ουρά και κάνοντας drop packets.
    Θέλει προσοχή γιατί έχουμε διαφορετική εξάρτηση σε κάθε πρωτόκολλο.
    6. Επειδή δεν έχω ασχοληθεί όπως σου είπα με Edgerouter, δίνεις προτεραιότητες ή απλά κάνεις ένα γενικό bw limit;
    | "Anyone can build a fast CPU.
    | The trick is to build a fast system."
    |____________Seymour Cray...

  3. #3
    Εγγραφή
    05-10-2012
    Ηλικία
    41
    Μηνύματα
    44
    Downloads
    0
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    50633/5495
    ISP
    ΟΤΕ Conn-x
    DSLAM
    ΟΤΕ - ΜΥΤΙΛΗΝΙΟΙ
    Router
    Speedport Plus+ NetdumaR1
    SNR / Attn
    9.7(dB) / 16.0(dB)
    Path Level
    Fastpath
    1. Φυσικά μπορεί να σου δώσει διαφορετικές ενδείξεις εάν το QOS είναι λάθος ρυθμισμένο πχ. κάνεις speedtest στη μια το μεσημέρι έχεις download 27Mbps και upload 2Mbps ...οπότε βάζεις 95% του download που είναι 25,65Mbps και upload 1,90Mbps....bufferbloat έχεις τριπλό Α+......Εάν όμως στις 4 το μεσημέρι πχ δεν έχεις 27Mbps και 2Mbps αλλά έχεις download 25Mbps και upload 1,6Mbps το QOS αυτόματα είναι "σπασμένο" και έχεις bufferbloat διότι είναι ρυθμισμένο στο 25,65Mbps ενώ έχεις 25Mbps και στο upload είναι ρυθμισμένο στο 1,90Mbps ενώ εκείνη την ώρα έχεις 1,6Mbps.

    Δεν κάνει speedtest στο dsl reports...εκεί μετράς εσύ χειροκίνητα το bufferbloat....speedtest για να πάρει τιμές κάνει μέσω του speedtest.net με τον κοντινότερο σέρβερ βάση ping.
    Πριν κάνει το τεστ στο speedtest.net για να πάρει τιμές download και upload απενεργοποιεί τελείως το qos εκτελώντας τις εντολές
    sudo tc qdisc del dev eth0 root και sudo tc qdisc del dev ifb4eth0 root έτσι ώστε οι τιμές που θα πάρει να είναι αξιόπιστες.
    Εφόσον είναι σωστά ρυθμισμένο το QOS στο dslreports όταν κάνεις τεστ για bufferbloat πάντα παίρνεις τις ίδιες τιμές όσο αφορά το bufferbloat ...τριπλό Α+ πάντα.

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

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

    Το traffic shaping που κάνει το CAKE στην κυκλοφορία ακόμα και στην είσοδο διατηρεί τα υπερβολικά πακέτα σε μια ουρά και στη συνέχεια προγραμματίζει την περίσσεια των πακέτων για μεταγενέστερη μετάδοση. Το αποτέλεσμα της διαμόρφωσης της κίνησης είναι ο εξομαλούμενος ρυθμός εισόδου των πακέτων.


    Στο download εσύ δεν έχεις bufferbloat?

    3. Ένα speedtest σε schedule γίνεται προκειμένου να έχεις πάντα την πραγματική ταχύτητα της γραμμής για να γίνει σωστή ρύθμιση στο CAKE..την συμφόρηση στο δίκτυο μου την ελέγχο με το CAKE ..η αχίλλειος πτέρνα όμως όλων των traffic shapers είναι ότι ενώ μια δεδομένη στιγμή το έχεις ρυθμίσει σωστά εάν πχ. κάνεις μια επανεκκίνηση στο ρούτερ και συγχρονίσει με μεγαλύτερη η μικρότερη ταχύτητα αυτόματα το QOS είναι "σπασμένο'.Σε αυτό το "πρόβλημα" δίνουμε μια κάποια λύση.

    4/5. Δεν είναι bandwidth limit είναι traffic shaping...Όπως ανέφερα και παραπάνω αυτό αλλάζει το default είναι παράδειγμα από τον KayOneX που έχει χάλια cable VDSL γραμμή και το έχει στο 70% αλλά δεν τον νοιάζει και πολύ....αν κοιτάξεις τις φωτό παρόλο το 70% έχει πάνω από 100Mbps download και 30Mbps upload.
    Εγώ χρησιμοποιώ στο δικό μου 95%.


    6. Ένα γενικό traffic shaping στο 95% της γραμμής... εξαρτάται επίσης και από το ρούτερ την μνήμη κτλ πχ. το Edgerouter Χ δεν θα μπορούσε με καμία δύναμη να διαχειριστεί QOS με γραμμή 200Mbps download.
    Μπες στην εξής λογική...είμαι gamer...σε καμία περίπτωση δεν θέλω packet drop..ειδικά στα udp πακέτα τον λόγο τον καταλαβαίνεις.Για αυτό και το QOS στο download δεν θέλουμε να "κάθονται" πακέτα στο buffer και τελικά να γίνονται drop η να καθυστερούν.

    Για "καλό" έβαλα τον οδηγό...είναι μια ανέξοδη λύση για όσους έχουν το Edgerouter X η οποιοδήποτε Edgerouter.
    Κάνει ότι κάνει και το Evenroute IQrouter
    Απλά δεν έχει γραφικό περιβάλλον.

  4. #4
    Εγγραφή
    28-03-2006
    Περιοχή
    KV G434
    Ηλικία
    49
    Μηνύματα
    42.180
    Downloads
    23
    Uploads
    0
    Τύπος
    FTTH
    Ταχύτητα
    310/31
    ISP
    Cosmote
    DSLAM
    ΟΤΕ - ΕΡΜΟΥ
    Router
    RB4011iGS+5 ONT: G-010G-R
    1. Σου είπα για το τεστ που αναφέρεις για τον λόγο ότι μπορείς να καταλήξεις σε λάθος συμπεράσματα.
    Και εξηγώ:
    Τρέχεις 4-5 φορές το τεστ και κάθε φορά σου δίνει άλλη ένδειξη.
    Επίσης άλλη ένδειξη παίρνεις και με διαφορετικό browser.
    Σε τι συμπέρασμα καταλήγεις για το QoS σου;
    Εξάλειψες ή όχι το bufferbloat;

    Επίσης...
    Δεν έχει σημασία που κάνεις το speedtest.
    Ένα speedtest θέλε κάποια δευτερόλεπτα για να πραγματοποιηθεί.
    Εσύ σε αυτόν τον χρόνο κάνεις disbable όλο το QoS.
    Το θεωρώ τελείως λάθος.
    Με αυτόν τον τρόπο υπάρχει στατιστική πιθανότητα μεγάλη να πέσεις σε φόρτο.
    Δηλαδή... έστω ότι εκείνη την ώρα η γραμμή σου είναι στο 100%.
    Εσύ κόβεις τελείως το QoS με αποτέλεσμα να γίνονται όλα μπάχαλο και ταυτόχρονα πας να τρέξεις ένα speedtest.
    Αν σου τρέξει το speedtest (γιατί αν κατεβάζεις torrent στο 100% απλά χαιρέτατο το speedtest με κλειστό το qos), τι τιμές θα πάρεις από το speedtest;

    2. QoS μπορείς να κάνεις είτε με shaping είτε με schedule.
    Δεν υπάρχει 100% σωστή λύση γιατί απλά δεν θα συζητούσαμε τώρα.
    Εξαρτάται από το πρωτόκολλο και την εφαρμογή καθώς και την χρήση που κάνεις.
    Έτσι προσδιορίζεις για το αν θα κινηθείς στην μια ή στην άλλη λύση.
    Στο sw λοιπόν έχεις μια κίνηση από τον πάροχο της τάξης πχ των 200Μ γιατί εκεί συγχρονίζει το modem σου.
    Περνάνε στο ρούτερ και τα στέλνεις στους χρήστες.
    Αν στο εσωτερικό δίκτυο έχεις συνδέσεις 100Μ τότε ναι θα έχεις bottleneck.
    Αν όμως παίζεις με 1G που το θεωρώ standard τότε δεν υπάρχει καν θέμα.
    Από που θα σου καθυστερήσουν τα πακέτα για να έχεις πρόβλημα;
    Πόσο μάλιστα για συνδέσεις <=100Μ.
    Αν λοιπόν ορίσεις QoS στο dw τότε απλά εσύ καθυστερείς τα πακέτα εσκεμμένα.
    Πράγμα που δεν βλέπω τον λόγο να κάνεις.
    πχ σου ήρθε το Α πακέτο γρηγορότερα από το Β.
    Γιατί να το φρενάρεις και να μην το στείλεις κατευθείαν, μιας και δεν έχεις bottleneck;
    Εσύ απλά το κρατάς και περιμένεις να σου έρθει και το Β ώστε να πεις μετά ότι το Β προηγείται του Α.
    Άρα θα στείλω πρώτα το Β και μετά το Α.
    Λάθος λογική.
    Σε περιπτώσεις που δεν υπάρχει bottleneck δεν κάνουμε QoS.

    3. Πόση διαφορά έχει το κλείδωμα σε vdsl και μάλιστα όταν παίρνεις από καμπίνα;
    Μέχρι 100Μ δεν βλέπω να παίζει καμία διαφορά.
    Ούτε 1Μ.
    Σε 200Μ πόση διαφορά βλέπεις;

    4/5/6. Traffic shaping χωρίς drop packets δεν μπορείς να έχεις.
    Το traffic shaping αυτό που κάνει είναι να σου κάνει drop όλα τα πακέτα που δεν χωράνε στην ουρά.
    Το schedule κρατάει τα πακέτα στην ουρά αλλά προσθέτει delay.
    Σε up βολεύει το shaping καθώς το κόστος της επανεκπομπής πακέτων είναι αμελητέο.
    Σε tcp είναι ευεργετικό και σε udp δεν δημιουργεί κανένα πρόβλημα.
    Σε dw όμως και τα δύο δημιουργούν πρόβλημα.
    Αν πρέπει να διαλέξεις, διαλέγεις το λιγότερο χειρότερο, για εσένα.

    Επίσης...
    Το διάγραμμα που δείχνεις ή είναι λάθος ή αναφέρεται σε άλλα πράγματα.
    Δεν κάνει αυτό το πράγμα το shaping.
    Δες εδώ. Η θεωρία είναι η ίδια. Δεν παίζει ρόλο αν είσαι σε ΜΤ/CISCO/Ubiquiti.

    Καλά έκανες και έβαλες τον οδηγό.
    Αντίστοιχο έχω και εγώ για ΜΤ.
    Απλά κάνω κάποιες υποδείξεις/παρατηρήσεις/επισημάνσεις.
    | "Anyone can build a fast CPU.
    | The trick is to build a fast system."
    |____________Seymour Cray...

  5. #5
    Εγγραφή
    05-09-2014
    Μηνύματα
    426
    Downloads
    1
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    100/11
    ISP
    Cosmote
    DSLAM
    ΟΤΕ - ΔΑΦΝΗ
    Router
    EdgeRouter X
    SNR / Attn
    11(dB) / 11(dB)
    Path Level
    Interleaved
    Παράθεση Αρχικό μήνυμα από Knomax Εμφάνιση μηνυμάτων
    Τι κάνουν τα script :

    Εξαλείφουν το φαινόμενο bufferbloat και τις αρνητικές επιπτώσεις του.
    Εφαρμόζει τον αλγόριθμο Cake στο upload και στο download σας.


    Εξαλείφει την συμφόρηση στο δίκτυο σας περιορίζοντας το εύρος στο 70% του συνολικού εύρους ζώνης που έχετε διαθέσιμο. (η τιμή μπορεί να αλλάξει πχ 80%,85% κτλ.)

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

    Μετά την επανεκκίνηση, περιμένετε περίπου 5 λεπτά μέχρι να αρχίσετε να χρησιμοποιείτε το ρούτερ σας για σελίδες / downloads / gaming. Η βελτιστοποίηση της γραμμής αρχίζει 3 λεπτά μετά την ολοκλήρωση της διαδικασίας εκκίνησης του ρούτερ. Στη συνέχεια εκτελείται ένα speedtest, υπολογίζει το 70% για το download και για το upload, εφαρμόζει τον αλγόριθμο CAKE για την διόρθωση του bufferbloat και δημιουργεί ένα χρονοπρογραμματιστή για να ξανα-
    βελτιστοποιήσει την γραμμή σας ανά μια ώρα, επαναλαμβάνοντας τα προηγούμενα βήματα.

    Να τονίσω ότι ακόμα και αν παίζουμε εκείνη την ώρα ΔΕΝ χάνουμε την σύνδεση μας πχ στο ps4 να μας κάνει sign out..απλά για κάποια δευτερόλεπτα ίσως να δούμε ελάχιστο “lag” σαν να είμαστε σε κάποιο χάλια lobby...Δεν νομίζω να πειράζει αυτό..τις περισσότερες φορές δεν θα το προσέξετε καν.
    Θα ήταν προτιμότερο να έπαιρνε τις τιμές απευθείας από το Modem και να υπολόγιζε από εκεί τις τιμές που πρέπει να βάλει στο QoS.
    Όπως ειπώθηκε, το Speedtest μπορεί να δείξει λάθος αποτελέσματα όταν υπάρχει κ' άλλο Traffic παράλληλα.
    Ναι, όταν η γραμμή είναι dead-idle, μπορεί το Speedtest να δείξει αν υπάρχει μπούκωμα στη μεριά του παρόχου αλλά λίγο δύσκολο εδώ στην Ελλάδα.
    Μπορεί να υπάρχουν περιπτώσεις, δεν το αποκλείω, αλλά είναι ελάχιστες.

    Μια ακόμη πιο σωστή μέθοδος για να υπολογίσεις το Traffic σε περίπτωση μπουκώματος (κατ' εμέ πάντα), είναι να μετρήσεις το Throughput στο Interface από το οποίο βγαίνεις για το Internet.
    - Ξεκίνα το Speedtest σου με κλειστό το QoS για να γεμίσεις τη γραμμή με Traffic (ανεξάρτητα από το αν κάνεις χαμό με Torrents).
    - Μέτρα το Throughput στο Interface. Τις βλέπεις τις τιμές ήδη στο GUI, φαντάζομαι δεν θα είναι δύσκολο να βγάλεις έναν μέσο όρο μερικών δευτερολέπτων σε Script.
    - Κλείσε το Speedtest και βάλε τις τιμές που πήρες από το Interface (ΌΧΙ από το Speedtest) στο QoS (με τα ανάλογα ποσοστά).
    Interface εννοώ την Ethernet θύρα, όχι το PPPoE Interface.

    Έτσι είτε κάνεις χαμό με Torrents, είτε είναι idle η γραμμή, φροντίζεις με κάποιο Speedtest να τερματίσεις τη γραμμή (αν δεν τερματίζει ήδη με τα Torrents) και παίρνεις δύο αριθμούς (Up & Down) πολύ κοντά στο πραγματικό σου Throughput.
    Δεν θα αναφερθούμε στο ότι είναι Flawed αυτή η μέθοδος αν αρχίσεις να βαράς το Upload με εκατοντάδες Streams (βλέπε στο Flent το rrul_100_up) και βλέπεις αστρονομικές τιμές, αλλά νομίζω ότι είναι ένας πολύ πιο σοβαρός τρόπος μέτρησης χωρίς να τρέχεις γύρο γύρο και να κλείνεις υπολογιστές για να μην τρώνε Bandwidth την ώρα που τρέχει το Script σου.
    Διαφωνώ στο ότι πρέπει να τρέχει κάποιο Script, συνήθως είναι Set-and-Forget το QoS όταν το Bandwidth είναι σταθερό ή έχει μικρές μεταβολές.
    Αν το λειτουργείς σε LTE/WISP όπου τα Link Rates αλλάζουν, εκεί τα πράγματα είναι δύσκολα.
    Ίσως βοηθήσει το autorate-ingress αλλά δεν το έχω δοκιμάσει.

    Παράθεση Αρχικό μήνυμα από Knomax Εμφάνιση μηνυμάτων
    Στον φάκελο VDSL έχουμε:

    pppoe-ptm Εάν η σύνδεση σας είναι τέτοιου τύπου.

    Εάν χρησιμοποιείται πχ. Το ρούτερ του ΟΤΕ σε passthrough και έχετε το ρούτερ σας να κάνει δεύτερη κλήση pppoe θα χρησιμοποιήσετε το παρακάτω.

    bridged-ptm Εάν η σύνδεση σας είναι τέτοιου τύπου.(Για τους περισσότερους χρήστες)

    ***Έχει συμπεριληφθεί και το ether-vlan το οποίο είναι 4 bytes.***
    Γιατί bridged-ptm; Με PPPoE έχουμε πρόσβαση στο Internet από τους (κύριους) παρόχους εδώ στην Ελλάδα, όχι απευθείας μέσω DHCP/Static.

    Επίσης να φανταστώ ότι δεν δουλεύει με το Advanced Queue.

    Προσωπικά θα ενεργοποιούσα το ECN επίσης και το Upstream.
    Είναι προτιμότερο να φας ελάχιστα παραπάνω delay όταν βαρέσεις το όριο, παρά να το κάνεις drop (packet loss) όταν παίζεις online.
    Αν παλεύεις με χαμηλά Uploads (π.χ. ADSL), τότε ναι, κράτα το ECN κλειστό.
    Αυτό στο λέω μετά από ώρες δοκιμών στα Battlefield με το Network Graph ανοιχτό. Βέβαια εγώ έκανα τις δοκιμές με τον fq_codel αλλά δεν χάνεις κάτι να το δοκιμάσεις στον cake.

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    2. QoS μπορείς να κάνεις είτε με shaping είτε με schedule.
    Δεν υπάρχει 100% σωστή λύση γιατί απλά δεν θα συζητούσαμε τώρα.
    Εξαρτάται από το πρωτόκολλο και την εφαρμογή καθώς και την χρήση που κάνεις.
    Έτσι προσδιορίζεις για το αν θα κινηθείς στην μια ή στην άλλη λύση.
    Στο sw λοιπόν έχεις μια κίνηση από τον πάροχο της τάξης πχ των 200Μ γιατί εκεί συγχρονίζει το modem σου.
    Περνάνε στο ρούτερ και τα στέλνεις στους χρήστες.
    Αν στο εσωτερικό δίκτυο έχεις συνδέσεις 100Μ τότε ναι θα έχεις bottleneck.
    Αν όμως παίζεις με 1G που το θεωρώ standard τότε δεν υπάρχει καν θέμα.
    Από που θα σου καθυστερήσουν τα πακέτα για να έχεις πρόβλημα;
    Πόσο μάλιστα για συνδέσεις <=100Μ.
    Αν λοιπόν ορίσεις QoS στο dw τότε απλά εσύ καθυστερείς τα πακέτα εσκεμμένα.
    Πράγμα που δεν βλέπω τον λόγο να κάνεις.
    πχ σου ήρθε το Α πακέτο γρηγορότερα από το Β.
    Γιατί να το φρενάρεις και να μην το στείλεις κατευθείαν, μιας και δεν έχεις bottleneck;
    Εσύ απλά το κρατάς και περιμένεις να σου έρθει και το Β ώστε να πεις μετά ότι το Β προηγείται του Α.
    Άρα θα στείλω πρώτα το Β και μετά το Α.
    Λάθος λογική.
    Σε περιπτώσεις που δεν υπάρχει bottleneck δεν κάνουμε QoS.
    Στο εξήγησε λίγο περίεργα.
    Δεν καθυστερεί εσκεμμένα το Traffic.
    Ο Cake κοιτάει by default Source IP + Port και Destination IP + Port. Έτσι δημιουργεί τα Flows και έτσι κάνει διάκριση μεταξύ των συσκευών στο δίκτυο (triple-isolate).
    Κρατάει όλα τα Flows "ίσα και όμοια", κάνοντας drop (ή ECN mark πρώτα αν είναι ενεργό) τα Flows τα οποία ξεπερνούν το όριο.
    Δεν λειτουργεί όπως το κλασικό FIFO όπου έχεις έναν σταθερό buffer και αν τον βαρέσεις, κάνεις Tail Drop.
    Υπάρχει κάποιο Queue αλλά δεν κρατάει κάτι ουσιαστικά, απλά κάνει Head Drop για να κάνει Signal στο TCP να κόψει λίγο τον ρυθμό με τον οποίο στέλνει.
    Δεν πρόκειται να το δεις να σου δίνει ποτέ το Β πριν από το Α. Το μόνο που θα δεις είναι να λείπει το Α αν το συγκεκριμένο Flow πέρασε το όριο.
    Μιλάμε για μακελειό σε UDP Traffic αν γινόταν αυτό.

    Περισσότερα εδώ.
    https://www.bufferbloat.net/projects...CakeTechnical/

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    3. Πόση διαφορά έχει το κλείδωμα σε vdsl και μάλιστα όταν παίρνεις από καμπίνα;
    Μέχρι 100Μ δεν βλέπω να παίζει καμία διαφορά.
    Ούτε 1Μ.
    Σε 200Μ πόση διαφορά βλέπεις;
    Φαντάζομαι θα αναφέρεται στην περίπτωση όπου δεν συγχρονίζει ακριβώς στο Maximum αλλά πιο κάτω.
    Βάλε και το SRA να είναι ενεργοποιημένο και να ρίχνει σιγά σιγά τον συγχρονισμό...
    Τελευταία επεξεργασία από το μέλος NinjaMiltos : 27-10-18 στις 05:28.

  6. #6
    Εγγραφή
    05-10-2012
    Ηλικία
    41
    Μηνύματα
    44
    Downloads
    0
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    50633/5495
    ISP
    ΟΤΕ Conn-x
    DSLAM
    ΟΤΕ - ΜΥΤΙΛΗΝΙΟΙ
    Router
    Speedport Plus+ NetdumaR1
    SNR / Attn
    9.7(dB) / 16.0(dB)
    Path Level
    Fastpath
    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    1. Σου είπα για το τεστ που αναφέρεις για τον λόγο ότι μπορείς να καταλήξεις σε λάθος συμπεράσματα.
    Και εξηγώ:
    Τρέχεις 4-5 φορές το τεστ και κάθε φορά σου δίνει άλλη ένδειξη.
    Επίσης άλλη ένδειξη παίρνεις και με διαφορετικό browser.
    Σε τι συμπέρασμα καταλήγεις για το QoS σου;
    Εξάλειψες ή όχι το bufferbloat;
    Κοίτα εάν κάποιος έχει βάλει 20 extensions στον browser και έχει "γονατίσει" και προσπαθεί να πάρει και όσο γίνεται σωστές τιμές...ε τι να πω.Στο συμπέρασμα που καταλήγω είναι ότι το εξάλειψα...από την στιγμή που παίρνω Α+ στο bufferbloat σε όλη την διάρκεια της ημέρας και κοντά στις πραγματικές μου ταχύτητες θεωρώ ότι είμαι εντάξει.


    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    Επίσης...
    Δεν έχει σημασία που κάνεις το speedtest.
    Όσες φορές πήρα τις τιμές που μου έδινε το dsl reports και από αυτές έβαλα το 95% είτε στο edgerouter x,είτε στο gargoyle,είτε στο LEDE/OPENWRT πάντα το bufferbloat ήταν ότι να'ναι όταν έκανα τεστ μετά.

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    Ένα speedtest θέλε κάποια δευτερόλεπτα για να πραγματοποιηθεί.
    Εσύ σε αυτόν τον χρόνο κάνεις disbable όλο το QoS.
    Το θεωρώ τελείως λάθος.
    Με αυτόν τον τρόπο υπάρχει στατιστική πιθανότητα μεγάλη να πέσεις σε φόρτο.
    Δηλαδή... έστω ότι εκείνη την ώρα η γραμμή σου είναι στο 100%.
    Εσύ κόβεις τελείως το QoS με αποτέλεσμα να γίνονται όλα μπάχαλο και ταυτόχρονα πας να τρέξεις ένα speedtest.
    Αν σου τρέξει το speedtest (γιατί αν κατεβάζεις torrent στο 100% απλά χαιρέτατο το speedtest με κλειστό το qos), τι τιμές θα πάρεις από το speedtest;
    Μάλλον εξαρχής δεν εξήγησα τον προσανατολισμό αυτών των scripts..μπες στην λογική ενός gamer..γιατί προς τα εκεί είναι ο προσανατολισμός...κάποιος ας πούμε "σκληροπυρηνικός" gamer που ξέρει κάποια πράγματα δεν υπάρχει περίπτωση την ώρα που παίζει να έχει και άλλα πράγματα να γονατίζουν την γραμμή defacto αυτό.


    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    3. Πόση διαφορά έχει το κλείδωμα σε vdsl και μάλιστα όταν παίρνεις από καμπίνα;
    Μέχρι 100Μ δεν βλέπω να παίζει καμία διαφορά.
    Ούτε 1Μ.
    Σε 200Μ πόση διαφορά βλέπεις;
    Έχω VDSL 30αρι του ΟΤΕ απο το interface του speedport πάντα δείχνει συγχρονισμό 29999/2999...αλλά πραγματική ταχύτητα όταν το τεστάρεις είναι πχ 27Mbps download και 2,7Mbps upload...βάζεις το 95% απο αυτά...έλα ντε όμως που απο το μεσημέρι και μετά που γυρνάνε όλοι από τα σχολεία,δουλειές κτλ και αρχίζουν να χρησιμοποιούν ιντερνετ στα σπίτια τους αν το τεστάρω ξανά δεν έχω 27/2,7Mbps αλλά περίπου 25-27 download και 2,3-2,5Mbps upload και βγαίνει το qos off γιατί με άλλες τιμές το έχω ρυθμίσει.Υπόψιν μένω Σάμο..αυτό συμβαίνει από το μεσημέρι και μετά..γιατί συμβαίνει?Δεν ξέρω..με άλλους παρόχους όπως πχ forthnet που ήμουνα πρίν ακόμα χειρότερα..adsl 24αρι και τα απογεύματα μπορεί να είχες 12Mbps...και το βράδυ ξανά 21Mbps.

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    4/5/6. Traffic shaping χωρίς drop packets δεν μπορείς να έχεις.
    Το traffic shaping αυτό που κάνει είναι να σου κάνει drop όλα τα πακέτα που δεν χωράνε στην ουρά.
    Το schedule κρατάει τα πακέτα στην ουρά αλλά προσθέτει delay.
    Σε up βολεύει το shaping καθώς το κόστος της επανεκπομπής πακέτων είναι αμελητέο.
    Σε tcp είναι ευεργετικό και σε udp δεν δημιουργεί κανένα πρόβλημα.
    Σε dw όμως και τα δύο δημιουργούν πρόβλημα.
    Αν πρέπει να διαλέξεις, διαλέγεις το λιγότερο χειρότερο, για εσένα.
    Αν δεν χρησιμοποιήσω καθόλου qos στο download έχω bufferbloat με βάση το dslreports περίπου 50ms...

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    Επίσης...
    Το διάγραμμα που δείχνεις ή είναι λάθος ή αναφέρεται σε άλλα πράγματα.
    Δεν κάνει αυτό το πράγμα το shaping.
    Δες εδώ. Η θεωρία είναι η ίδια. Δεν παίζει ρόλο αν είσαι σε ΜΤ/CISCO/Ubiquiti.
    Το διάγραμμα είναι από την σελίδα της Cisco εξηγώντας το shaping και γενικά το buffrbloat.

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    Καλά έκανες και έβαλες τον οδηγό.
    Αντίστοιχο έχω και εγώ για ΜΤ.
    Απλά κάνω κάποιες υποδείξεις/παρατηρήσεις/επισημάνσεις.
    Μάλλον δεν έκανα καλά...εσύ το βλέπεις από άλλη "μεριά"...για να μην παρεξηγηθώ...εσύ έχεις στο μυαλό σου τον χρήστη που βλέπει βίντεο στο youtube.. ταυτόχρονα κατεβάζει και 10 ταινίες blueray...έχει και facebook ανοιχτό στο κινητό...έχει και ΟΤΕTV μέσω ίντερνετ....εγώ αναφέρομαι στον χρήστη που την ώρα που "παίζει" δεν τον ενδιαφέρει κάτι άλλο αλλά θέλει το qos ρυθμισμένο για όσες ώρες παίζει να μην έχει buferbloat.;Έχεις ασχοληθεί με online gaming σε κονσόλα?πχ playstation?Μέσω wireshark το 70% των πακέτων είναι udp στην θύρα 3074 όσες φορές πήγα να βάλω προτεραιότητα σε αυτά τα πακέτα... online είχε χάλια hit registration θέλει και τα πακέτα ack προτεραιότητα...έχει και πολλά με tcp flag push..σε ποιο να πρωτο δώσεις προτεραιότητα?Κοίταξα να ορίσω με βάση το μέγεθος των πακέτων...άλλα udp είναι 90 bytes ...άλλα 400 bytes.Απο χόμπι ασχολούμαι..δεν είμαι τεχνικός δικτύων η κάτι τέτοιο...διαβάζω να μάθω και μετά trial and error....εμπειρικά μόνο να σου πω ότι πολλά πράγματα που λέμε εδώ όσο αφορά πιο είναι σωστό και τι λάθος..έχουν διαφορετικό αντίκτυπο όταν μιλάμε για online gaming..κάτι που για χρήση στον υπολογιστή..σερφάρισμα κτλ μπορεί να είναι σωστό και να δουλεύει και όταν πηγαίνεις να παίξεις..χάλια....και κάτι που φαίνεται "παράδοξο" για καθημερινή χρήση στο online gaming να κάνεις "παπάδες"...μιλάω για fps games που μια "σφαίρα" που δεν κάνει register είναι η διαφορά αν ζεις η αν πεθαίνεις.






    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    Θα ήταν προτιμότερο να έπαιρνε τις τιμές απευθείας από το Modem και να υπολόγιζε από εκεί τις τιμές που πρέπει να βάλει στο QoS.
    Όπως ειπώθηκε, το Speedtest μπορεί να δείξει λάθος αποτελέσματα όταν υπάρχει κ' άλλο Traffic παράλληλα.
    Ναι, όταν η γραμμή είναι dead-idle, μπορεί το Speedtest να δείξει αν υπάρχει μπούκωμα στη μεριά του παρόχου αλλά λίγο δύσκολο εδώ στην Ελλάδα.
    Μπορεί να υπάρχουν περιπτώσεις, δεν το αποκλείω, αλλά είναι ελάχιστες.
    Το modem δείχνει πάντα 29999/2999 αλλά οι πραγματικές είναι άλλες...επίσης στο dslreports με κλειστό qos κλτ και τελείως ήσυχο το δίκτυο (μόνο ο υπολογιστής που θα κάνει το τεστ) αφού ολοκληρωθεί το τεστ στο idle η γραμμή είναι περίπου 60ms latency...αυτό γιατί?

    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    Μια ακόμη πιο σωστή μέθοδος για να υπολογίσεις το Traffic σε περίπτωση μπουκώματος (κατ' εμέ πάντα), είναι να μετρήσεις το Throughput στο Interface από το οποίο βγαίνεις για το Internet.
    - Ξεκίνα το Speedtest σου με κλειστό το QoS για να γεμίσεις τη γραμμή με Traffic (ανεξάρτητα από το αν κάνεις χαμό με Torrents).
    - Μέτρα το Throughput στο Interface. Τις βλέπεις τις τιμές ήδη στο GUI, φαντάζομαι δεν θα είναι δύσκολο να βγάλεις έναν μέσο όρο μερικών δευτερολέπτων σε Script.
    - Κλείσε το Speedtest και βάλε τις τιμές που πήρες από το Interface (ΌΧΙ από το Speedtest) στο QoS (με τα ανάλογα ποσοστά).
    Interface εννοώ την Ethernet θύρα, όχι το PPPoE Interface.

    Έτσι είτε κάνεις χαμό με Torrents, είτε είναι idle η γραμμή, φροντίζεις με κάποιο Speedtest να τερματίσεις τη γραμμή (αν δεν τερματίζει ήδη με τα Torrents) και παίρνεις δύο αριθμούς (Up & Down) πολύ κοντά στο πραγματικό σου Throughput.
    Δεν θα αναφερθούμε στο ότι είναι Flawed αυτή η μέθοδος αν αρχίσεις να βαράς το Upload με εκατοντάδες Streams (βλέπε στο Flent το rrul_100_up) και βλέπεις αστρονομικές τιμές, αλλά νομίζω ότι είναι ένας πολύ πιο σοβαρός τρόπος μέτρησης χωρίς να τρέχεις γύρο γύρο και να κλείνεις υπολογιστές για να μην τρώνε Bandwidth την ώρα που τρέχει το Script σου.
    Διαφωνώ στο ότι πρέπει να τρέχει κάποιο Script, συνήθως είναι Set-and-Forget το QoS όταν το Bandwidth είναι σταθερό ή έχει μικρές μεταβολές.
    Αν το λειτουργείς σε LTE/WISP όπου τα Link Rates αλλάζουν, εκεί τα πράγματα είναι δύσκολα.
    Ίσως βοηθήσει το autorate-ingress αλλά δεν το έχω δοκιμάσει.
    Το interface είναι το eth0 και το PPPOE interface είναι parent στο eth0....πάλι "στατικό" δεν θα είναι το QOS?Ο Lochnair στο ubnt φόρουμ όταν τον ρώτησα είπε δεν θα βοηθήσει μπορεί να βοηθήσει το ack-filter ...στο upload.

    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    Γιατί bridged-ptm; Με PPPoE έχουμε πρόσβαση στο Internet από τους (κύριους) παρόχους εδώ στην Ελλάδα, όχι απευθείας μέσω DHCP/Static.
    Αυτό λάθος δικό μου..θα το διορθώσω...μπερδεύτηκα με το vlan που προσθέτει 4 bytes...sorry.

    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    Επίσης να φανταστώ ότι δεν δουλεύει με το Advanced Queue.
    Δεν το έχω δοκιμάσει..το CAKE δεν υπάρχει για την ώρα στο edgerouter ...πως θα δουλέψει στο Advance Queue..χρησιμοποιεί fq_codel,hfq,sfq και pfifo όχι CAKE.Δεν ξέρω αν δουλεύει αν τα κάνεις όλα χειροκίνητα μέσω terminal.

    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    Προσωπικά θα ενεργοποιούσα το ECN επίσης και το Upstream.
    Είναι προτιμότερο να φας ελάχιστα παραπάνω delay όταν βαρέσεις το όριο, παρά να το κάνεις drop (packet loss) όταν παίζεις online.
    Αν παλεύεις με χαμηλά Uploads (π.χ. ADSL), τότε ναι, κράτα το ECN κλειστό.
    Αυτό στο λέω μετά από ώρες δοκιμών στα Battlefield με το Network Graph ανοιχτό. Βέβαια εγώ έκανα τις δοκιμές με τον fq_codel αλλά δεν χάνεις κάτι να το δοκιμάσεις στον cake.
    Θα το δοκιμάσω...στο Openwrt πάντως και με ενεργό ECN δεν είχα δει κάποια διαφορά..μπορεί να μην το πρόσεξα..το openwrt το έχω σε ένα tplink wr1043nd-v3....θα το δοκιμάσω και στο edgerouter.

  7. #7
    Εγγραφή
    28-03-2006
    Περιοχή
    KV G434
    Ηλικία
    49
    Μηνύματα
    42.180
    Downloads
    23
    Uploads
    0
    Τύπος
    FTTH
    Ταχύτητα
    310/31
    ISP
    Cosmote
    DSLAM
    ΟΤΕ - ΕΡΜΟΥ
    Router
    RB4011iGS+5 ONT: G-010G-R
    @Knomax
    Όπως ανέφερα... κάνω το τεστ με διαφορετικούς browser και παίρνω τιμές από Α έως C στον κάθε ένα.
    Δεν μπορεί να έχεις την μια bufferbloat και την άλλη όχι.

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

    @NinjaMiltos
    Ξέρω πως λειτουργεί ο CAKE.
    Αυτό που λέω είναι ότι δεν χρειάζεται να υποβάλεις το dw σε οποιοδήποτε QoS.
    Έστω λοιπόν ότι δεν παίζεις καθόλου με τις πρωτεραιότητες που ανέφερα και περνάς όλο το traffic από μια μόνο ουρά.
    Από την στιγμή που ορίζεις ουρά παίζεις με buffer.
    Είτε fifo, είτε CAKE, είτε pcq, είτε sfq κλπ θα έχεις καθυστερήσεις.
    Αν έχεις μεγάλο buffer θα σου προσδώσει φυσικά καθυστερήσεις.
    Αν έχεις μικρό θα σου κάνει drop.
    (συνέχεια)

    @NinjaMiltos & @Knomax
    (συνέχεια)
    Drop σε dw πακέτα σημαίνει μεγάλες καθυστερήσεις.
    Και για να το πω και με ένα παράδειγμα που χρησιμοποιώ συνήθως.
    Έχεις μια λεωφόρο με 5 λωρίδες κυκλοφορίας και εσύ έχεις σε κάθε χρονική στιγμή το πολύ 3 αυτοκίνητα παράλληλα.
    Χρησιμοποιείς δηλαδή το πολύ 3 από τις 5 λωρίδες.
    Και ενώ έχεις ελεύθερες λωρίδες κυκλοφορίας, σε περίοδο αυξημένης κίνησης εσύ αντί να χρησιμοποιήσεις τις επιπλέον ελεύθερες λωρίδες, στήνεις διόδια και τους λες ότι θα περνάνε το πολύ 50 αυτοκίνητα ταυτόχρονα και αν έρθει το +1 θα το στείλεις πίσω με την δικαιολογία ότι έχεις φουλάρει.
    Με το παραπάνω σενάριο αποκλείεται να έχεις καλύτερη συμπεριφορά απ ότι αν άφηνες την κίνηση σε όλες τις λωρίδες.

    Με λίγα λόγια... ΔΕΝ ΚΑΝΟΥΜΕ ΠΟΤΕQoS ΣΕ DW.

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

    Από εκεί και ύστερα...
    Αν νομίζεις ότι σου παίζει σωστά και νομίζεις ότι σου κάνει την δουλειά σου... κράτα το.
    Στο θέμα με το ΜΤ θα δεις να αναιρούμε ουκ ολίγες φορές υλοποιήσεις που θεωρούσαμε ότι δούλευαν.
    | "Anyone can build a fast CPU.
    | The trick is to build a fast system."
    |____________Seymour Cray...

  8. #8
    Εγγραφή
    05-10-2012
    Ηλικία
    41
    Μηνύματα
    44
    Downloads
    0
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    50633/5495
    ISP
    ΟΤΕ Conn-x
    DSLAM
    ΟΤΕ - ΜΥΤΙΛΗΝΙΟΙ
    Router
    Speedport Plus+ NetdumaR1
    SNR / Attn
    9.7(dB) / 16.0(dB)
    Path Level
    Fastpath
    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    @Knomax
    Όπως ανέφερα... κάνω το τεστ με διαφορετικούς browser και παίρνω τιμές από Α έως C στον κάθε ένα.
    Δεν μπορεί να έχεις την μια bufferbloat και την άλλη όχι.
    Με διαφορετικούς browsers πάντα το ίδιο αποτέλεσμα έχω...φυσικά δεν μπορεί την μια να έχεις bufferbloat και μια όχι...μπορεί όμως το QOS σου μια να κάνει σωστά την "δουλειά" του και μια όχι.

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    Σχετικά με τους gamers που αναφέρεις... άρα δεν είναι ένα γενικό QoS που απευθύνεται σε όλους αλλά μόνο στην συγκεκριμένη ομάδα χρηστών.
    Πρέπει να γίνονται τέτοιες διευκρινίσεις γιατί οδηγούμαστε σε λάθος συμπεράσματα.
    Είπα ότι ο προσανατολισμός είναι προς τα εκεί..δεν είπα ότι είναι άχρηστο για all around χρήση...και οι σελίδες μου ανοίγουν αστραπιαία και βίντεο στο τάμπλετ παράλληλα.Μην είσαι αρνητικός υποθέσεις κάνεις... το δοκίμασες?Έίδες τα scripts πως το υλοποιούν?Έβαλα και την τηλεόραση να κάνει download ταινία μέσω ΟΤΕTV και ταυτόχρονα gaming,πάτησα να κάνει bufferbloat τεστ..πάνω από 4-5ms δεν ανεβαίνει ποτέ και download και upload.Και για κάθε μέρα κάνει.Αν έχει κάποιος edgerouter ας το δοκιμάσει...μόνο εγώ το έχω?

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    @NinjaMiltos
    Ξέρω πως λειτουργεί ο CAKE.
    Αυτό που λέω είναι ότι δεν χρειάζεται να υποβάλεις το dw σε οποιοδήποτε QoS.
    Έστω λοιπόν ότι δεν παίζεις καθόλου με τις πρωτεραιότητες που ανέφερα και περνάς όλο το traffic από μια μόνο ουρά.
    Από την στιγμή που ορίζεις ουρά παίζεις με buffer.
    Είτε fifo, είτε CAKE, είτε pcq, είτε sfq κλπ θα έχεις καθυστερήσεις.
    Αν έχεις μεγάλο buffer θα σου προσδώσει φυσικά καθυστερήσεις.
    Αν έχεις μικρό θα σου κάνει drop.
    (συνέχεια)
    Μάλλον αναφέρεσαι στο queue size το buffer δημιουργείται στην μνήμη και queue flood για αυτό κάνει drop ο αλγόριθμος.

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    @NinjaMiltos & @Knomax
    (συνέχεια)
    Drop σε dw πακέτα σημαίνει μεγάλες καθυστερήσεις.
    Και για να το πω και με ένα παράδειγμα που χρησιμοποιώ συνήθως.
    Έχεις μια λεωφόρο με 5 λωρίδες κυκλοφορίας και εσύ έχεις σε κάθε χρονική στιγμή το πολύ 3 αυτοκίνητα παράλληλα.
    Χρησιμοποιείς δηλαδή το πολύ 3 από τις 5 λωρίδες.
    Και ενώ έχεις ελεύθερες λωρίδες κυκλοφορίας, σε περίοδο αυξημένης κίνησης εσύ αντί να χρησιμοποιήσεις τις επιπλέον ελεύθερες λωρίδες, στήνεις διόδια και τους λες ότι θα περνάνε το πολύ 50 αυτοκίνητα ταυτόχρονα και αν έρθει το +1 θα το στείλεις πίσω με την δικαιολογία ότι έχεις φουλάρει.
    Με το παραπάνω σενάριο αποκλείεται να έχεις καλύτερη συμπεριφορά απ ότι αν άφηνες την κίνηση σε όλες τις λωρίδες.

    Με λίγα λόγια... ΔΕΝ ΚΑΝΟΥΜΕ ΠΟΤΕQoS ΣΕ DW.
    Σωστό το παραπάνω αλλά το CAKE δεν κάνει αυτό...το pcq μάλλον που έχει το ΜΤ ορίζεις ουρές..σωστά...ανάλογα πόσες ουρές και το μέγεθος τους "ξεχειλίζουν" η όχι.
    Το CAKE από την άλλη κάνει το εξής....δεν υπάρχει λεωφόρος...όσα αυτοκίνητα έρχονται φτιάχνει ξεχωριστό δρόμο για το καθένα (flows)..από το κάθε διόδιο περνάει ένα αυτοκίνητο..δεν περιμένει άλλο.Εάν ζητηθεί ένα πακέτο το στέλνει αμέσως παράμετροι πχ nat dual-dsthost....με βάση ποια ip το ζητάει.Στη συνέχεια υπολογίζεται ο χρόνος μετάδοσης του επόμενου πακέτου και μέχρι εκείνη τη στιγμή ο διαμορφωτής τοποθετείται σε λειτουργία έλλειψης (deficit mode).Ενώ βρίσκονται σε κατάσταση έλλειψης, τα πακέτα προγραμματίζονται χρησιμοποιώντας ένα χρονόμετρο παρακολούθησης (watchdog)... όποτε ένα πακέτο φθάνει πολύ σύντομα υπολογίζονται οι χρόνοι μετάδοσης για ένα συνεχές flow. Αυτό συνεχίζεται μέχρι να αποστραγγιστεί η ουρά (flow)

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    Μπορείτε να ρίξετε μια ματιά και στο αντίστοιχο θέμα που συζητάμε για τα ΜΤ.
    Έχουμε προτείνει πάρα πολλές υλοποιήσεις που λέμε ότι δούλευαν.
    Αλλά τελικά αποδείχθηκε ότι είτε δούλευαν σε κάποια χρονική στιγμή, είτε μας έδιναν την εντύπωση ότι δούλευαν.
    Προσωπικά εγώ έχω προτείνει πολλές υλοποιήσεις που άλλες ήταν θεωρητικά λάθος αλλά πρακτικά σωστές και άλλες το αντίθετο.
    Και πάλι μιλώντας για τον εαυτό μου, οτιδήποτε έχω ποστάρει, έχει γίνει κατόπιν αναρίθμητων τεστ και πάρα (μα πάρα) πολλών ωρών/ημερών δοκιμών.
    Γι αυτό είμαι πολύ επιφυλακτικός όταν διαβάζω ότι κάτι παίζει σωστά.
    Και μάλιστα όταν είναι και θεωρητικά λάθος (αναφέρομαι στο θέμα του dw).
    Συμφωνώ είναι trial and error....άπειρες ώρες διαβάσματος για το πως δουλεύει κάτι.Το έχουμε τεστάρει περίπου 20 ημέρες εγώ καθημερινή χρήση όχι μόνο gaming και με διάφορα σενάρια να δω που είναι τα όρια του...μέχρι τώρα με έχει εκπλήξει ευχάριστα.



    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    Από εκεί και ύστερα...
    Αν νομίζεις ότι σου παίζει σωστά και νομίζεις ότι σου κάνει την δουλειά σου... κράτα το.
    Στο θέμα με το ΜΤ θα δεις να αναιρούμε ουκ ολίγες φορές υλοποιήσεις που θεωρούσαμε ότι δούλευαν.
    Περί ορέξεως...κουβέντα κάνουμε..θα ήθελα πάντως αν το έχει και κανένας άλλος το edgerouter x να το δοκίμαζε.

  9. #9
    Εγγραφή
    05-09-2014
    Μηνύματα
    426
    Downloads
    1
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    100/11
    ISP
    Cosmote
    DSLAM
    ΟΤΕ - ΔΑΦΝΗ
    Router
    EdgeRouter X
    SNR / Attn
    11(dB) / 11(dB)
    Path Level
    Interleaved
    Παράθεση Αρχικό μήνυμα από Knomax Εμφάνιση μηνυμάτων
    Το modem δείχνει πάντα 29999/2999 αλλά οι πραγματικές είναι άλλες...επίσης στο dslreports με κλειστό qos κλτ και τελείως ήσυχο το δίκτυο (μόνο ο υπολογιστής που θα κάνει το τεστ) αφού ολοκληρωθεί το τεστ στο idle η γραμμή είναι περίπου 60ms latency...αυτό γιατί?
    Το 60ms που βλέπεις, είναι το RTT από εσένα, στον Server και πίσω πάλι σε εσένα.
    Μετράμε το Delta-Over-Idle και όχι το ίδιο το Latency. Είναι λογικό να έχεις 60ms μιας και ο Server δεν είναι στη χώρα μας.
    Αν εννοείς 60ms over idle, τότε ίσως ανεβαίνουν τα CRC στο Modem ή τρως μπούκωμα (αν όντως ισχύει αυτό που λες πιο πάνω).
    Ping Spikes μπορεί να σου κάνει και μια αργή συσκευή.
    Το ER-X είναι OK μέχρι τα ~150Mbps, μετά αρχίζουν τα παρατράγουδα (και αυτό αν δεν τρέχεις τίποτα άλλο παράλληλα).

    Παράθεση Αρχικό μήνυμα από Knomax Εμφάνιση μηνυμάτων
    Δεν το έχω δοκιμάσει..το CAKE δεν υπάρχει για την ώρα στο edgerouter ...πως θα δουλέψει στο Advance Queue..χρησιμοποιεί fq_codel,hfq,sfq και pfifo όχι CAKE.Δεν ξέρω αν δουλεύει αν τα κάνεις όλα χειροκίνητα μέσω terminal.
    Δεν βλέπω τον λόγο να μην δουλέψει, είναι όμως μανούρα αν κάνεις μια αλλαγή στο Advanced Queue. Θέλει πάλι μετά αλλαγή στο Script ώστε να συμβαδίζει το Advanced Queue με το Script.
    Ας ελπίσουμε ότι θα μπει επίσημα κάποια στιγμή όταν βγει σε Stable η v2 με το καινούριο Kernel.

    Παράθεση Αρχικό μήνυμα από Knomax Εμφάνιση μηνυμάτων
    Θα το δοκιμάσω...στο Openwrt πάντως και με ενεργό ECN δεν είχα δει κάποια διαφορά..μπορεί να μην το πρόσεξα..το openwrt το έχω σε ένα tplink wr1043nd-v3....θα το δοκιμάσω και στο edgerouter.
    Μιλάμε για διαφορές ~3%. Μια φορά στα 2-3 δευτερόλεπτα είχα Packet Loss της τάξης του 3% και το ECN το εξάλειψε.

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    @NinjaMiltos
    Ξέρω πως λειτουργεί ο CAKE.
    Αυτό που λέω είναι ότι δεν χρειάζεται να υποβάλεις το dw σε οποιοδήποτε QoS.
    Έστω λοιπόν ότι δεν παίζεις καθόλου με τις πρωτεραιότητες που ανέφερα και περνάς όλο το traffic από μια μόνο ουρά.
    Από την στιγμή που ορίζεις ουρά παίζεις με buffer.
    Είτε fifo, είτε CAKE, είτε pcq, είτε sfq κλπ θα έχεις καθυστερήσεις.
    Αν έχεις μεγάλο buffer θα σου προσδώσει φυσικά καθυστερήσεις.
    Αν έχεις μικρό θα σου κάνει drop.
    (συνέχεια)

    @NinjaMiltos & @Knomax
    (συνέχεια)
    Drop σε dw πακέτα σημαίνει μεγάλες καθυστερήσεις.
    Και για να το πω και με ένα παράδειγμα που χρησιμοποιώ συνήθως.
    Έχεις μια λεωφόρο με 5 λωρίδες κυκλοφορίας και εσύ έχεις σε κάθε χρονική στιγμή το πολύ 3 αυτοκίνητα παράλληλα.
    Χρησιμοποιείς δηλαδή το πολύ 3 από τις 5 λωρίδες.
    Και ενώ έχεις ελεύθερες λωρίδες κυκλοφορίας, σε περίοδο αυξημένης κίνησης εσύ αντί να χρησιμοποιήσεις τις επιπλέον ελεύθερες λωρίδες, στήνεις διόδια και τους λες ότι θα περνάνε το πολύ 50 αυτοκίνητα ταυτόχρονα και αν έρθει το +1 θα το στείλεις πίσω με την δικαιολογία ότι έχεις φουλάρει.
    Με το παραπάνω σενάριο αποκλείεται να έχεις καλύτερη συμπεριφορά απ ότι αν άφηνες την κίνηση σε όλες τις λωρίδες.

    Με λίγα λόγια... ΔΕΝ ΚΑΝΟΥΜΕ ΠΟΤΕQoS ΣΕ DW.

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

    Από εκεί και ύστερα...
    Αν νομίζεις ότι σου παίζει σωστά και νομίζεις ότι σου κάνει την δουλειά σου... κράτα το.
    Στο θέμα με το ΜΤ θα δεις να αναιρούμε ουκ ολίγες φορές υλοποιήσεις που θεωρούσαμε ότι δούλευαν.
    QoS στο Down, όχι, δεν έχει νόημα, μιας και το πακέτο είναι ήδη "στην πόρτα σου".

    Η διαφορά μας είναι ότι βάζουμε Bandwidth Limit πιο κάτω απ' ό,τι περνάει από τη γραμμή για να σταματήσει να μαζεύεται Traffic στους Buffers του ISP.
    Αν ΔΕΝ βάλεις κάποιον Queue Manager όμως, το αποτέλεσμα θα είναι το ίδιο με αυτό που κάνει ο ISP. Όλα τα πακέτα μαζεύονται σε έναν κουβά και αρχίζει και κάνει Dequeue με τη σειρά που ήρθαν, ενώ συνεχίζει και κάνει Drop τα υπόλοιπα όσο το Inbound Traffic ξεπερνά το Limit στον Shaper.
    Μόνο αν υπήρχε κάποιος τρόπος να φροντίσεις να περάσουν τα μικρά πακέτα μπροστά παρά να μείνουν πίσω στην Queue...

    Αυτό ακριβώς κάνει ο Cake. Κρατάει έναν πολύ μικρό Buffer και ξεχωρίζει σε Flows τα διάφορα Streams.
    Την ώρα του Congestion στη μεριά σου (εφόσον έβαλες Limit για τον λόγο που είπα παραπάνω), τότε βλέπει ότι μαζεύει πακέτα στους Buffers που δημιούργησε το Bandwidth Limit και αποφασίζει να κάνει Drop/Mark τα Flows που κάνουν μονοπώλιο.

    Παράθεση Αρχικό μήνυμα από deniSun Εμφάνιση μηνυμάτων
    Drop σε dw πακέτα σημαίνει μεγάλες καθυστερήσεις.
    Γι' αυτό τον λόγο έχει ενεργό το ECN by default στο Downstream.
    Το πακέτο έχει έρθει ήδη στο Router, αντί να το κάνει Drop και να ξαναπεράσει δεύτερη φορά αργότερα, απλά το δίνει στον παραλήπτη με ECN flag.
    Υπάρχουν περιπτώσεις όπου κάνει Drop και δεν σώνεται η κατάσταση μόνο με το ECN; Φυσικά.

    Ας το φέρω και εγώ στο παράδειγμα με τη λεωφόρο.
    Έχω Χ λωρίδες και τρέχουν όλα τα αυτοκίνητα παράλληλα μέχρι τα διόδια (Bandwidth Limit στο Router μου).
    Λέω ότι όσο μπορώ να τους εξυπηρετήσω γρήγορα και δεν μαζεύεται ουρά μέχρι το όριο που έχω ορίσει εγώ, όλοι περνάνε με τη σειρά που ήρθαν.
    Έρχεται λοιπόν η στιγμή όπου στα διόδια μου δεν προλαβαίνω να εξυπηρετήσω τους πάντες ώστε να διώξω τα αυτοκίνητα.
    Καταφθάνει ένα ασθενοφόρο και βλέπει κίνηση, με αποτέλεσμα να μείνει στην κίνηση χωρίς τρόπο διαφυγής μιας και όλοι εξυπηρετούνται με τη σειρά που ήρθαν.

    Εφαρμόζω την τεχνική "Cake" στα διόδια μου.
    Πλέον λίγο πριν φτάσουν τα αυτοκίνητα στα διόδια, τα ξεχωρίζω σε διάφορες λωρίδες (Flows. Αυτό γίνεται τη στιγμή που φτάνουν τα πακέτα στο Router).
    Έρχεται η στιγμή όπου ξαναγίνεται χαμός, με τη μόνη διαφορά ότι πάλι δεν μπορώ να τους εξυπηρετήσω όλους.
    Εδώ με βοηθάει η τεχνική που εφάρμοσα διότι όταν γίνεται χαμός, λέω STOP στα φορτηγά και στα αυτοκίνητα για να περάσει γρήγορα το ασθενοφόρο.

    Θυμίζει πάρα πολύ τις προτεραιότητες που ρυθμίζεις όταν φτιάχνεις μόνος σου τα Queues.
    Μόνο που αυτό προσπαθεί να το κάνει μόνο του, δίνοντας βάση στα μικρά πακέτα και στο να κρατάει ίσο το Bandwidth μεταξύ των Flows, παρά να κάνει μονοπώλιο το TCP και να κάνει Starve τα UDP επειδή γεμίζεις δίχως αύριο τους Buffers με "σαβούρα".

    Η όλη φασαρία γίνεται στο ποιος θα περάσει πρώτος από τον δικό σου τεχνητό Buffer που δημιούργησες όταν έβαλες Bandwidth Limit (για να σταματήσεις να βαράς τους Buffers του ISP).

    Εννοείται ότι δεν έχει κανένα απολύτως νόημα το QoS όταν δεν έχεις το Bottleneck εσύ (όταν δεν βάζεις Shaper).

    - - - Updated - - -

    Παράθεση Αρχικό μήνυμα από Knomax Εμφάνιση μηνυμάτων
    Το interface είναι το eth0 και το PPPOE interface είναι parent στο eth0....πάλι "στατικό" δεν θα είναι το QOS?Ο Lochnair στο ubnt φόρουμ όταν τον ρώτησα είπε δεν θα βοηθήσει μπορεί να βοηθήσει το ack-filter ...στο upload.
    Την μέθοδο αυτή την πρότεινα για να είσαι σίγουρος για τις τιμές.
    Αν έχεις Traffic τη στιγμή που τρέχει το Speedtest, θα σου βγάλει λάθος τιμές.
    Αν πάρεις τις τιμές από το ίδιο το Interface, δεν μπορεί να είναι παραπάνω το Bandwidth απ' ότι περνάει από το Modem σου (με μια μικρή απόκλιση συνήθως, ανάλογα πόσο σκληρά το βαράς με Traffic).
    Αν/Όταν σε κάνει Throttle ο ISP και βλέπεις 20 Mbps αλλά συγχρονίζεις στα 30, δεν πρόκειται να σου δείξει ποτέ το Interface 30, αφού 20 Mbps μόνο μπορείς να περάσεις.
    Και όχι, δεν είναι στατικό εφόσον βγάζεις το QoS και βλέπεις το πραγματικό σου Traffic όσο περνάει από το Interface (και όχι τον συγχρονισμό ή το Speedtest). Αρκεί να κάνεις εσύ generate traffic (οτιδήποτε) για να πάρεις τις τιμές που θέλεις.
    Τελευταία επεξεργασία από το μέλος NinjaMiltos : 27-10-18 στις 15:34.

  10. #10
    Εγγραφή
    05-10-2012
    Ηλικία
    41
    Μηνύματα
    44
    Downloads
    0
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    50633/5495
    ISP
    ΟΤΕ Conn-x
    DSLAM
    ΟΤΕ - ΜΥΤΙΛΗΝΙΟΙ
    Router
    Speedport Plus+ NetdumaR1
    SNR / Attn
    9.7(dB) / 16.0(dB)
    Path Level
    Fastpath
    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    Το 60ms που βλέπεις, είναι το RTT από εσένα, στον Server και πίσω πάλι σε εσένα.
    Μετράμε το Delta-Over-Idle και όχι το ίδιο το Latency. Είναι λογικό να έχεις 60ms μιας και ο Server δεν είναι στη χώρα μας.
    Αν εννοείς 60ms over idle, τότε ίσως ανεβαίνουν τα CRC στο Modem ή τρως μπούκωμα (αν όντως ισχύει αυτό που λες πιο πάνω).
    Ping Spikes μπορεί να σου κάνει και μια αργή συσκευή.
    Το ER-X είναι OK μέχρι τα ~150Mbps, μετά αρχίζουν τα παρατράγουδα (και αυτό αν δεν τρέχεις τίποτα άλλο παράλληλα).
    CRC δεν έχω στο modem..το ER-X λένε είναι οκ μέχρι τα 200Mbps αλλά μάλλον είναι πολύ αισιόδοξοι,θα συμφωνήσω μαζί σου..λιγότερο όριο έχει.

    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    Δεν βλέπω τον λόγο να μην δουλέψει, είναι όμως μανούρα αν κάνεις μια αλλαγή στο Advanced Queue. Θέλει πάλι μετά αλλαγή στο Script ώστε να συμβαδίζει το Advanced Queue με το Script.
    Ας ελπίσουμε ότι θα μπει επίσημα κάποια στιγμή όταν βγει σε Stable η v2 με το καινούριο Kernel.
    Είναι μανούρα όπως λες....στις beta που παρακολουθώ..κουβέντα δεν γίνεται αν θα έχει το Cake..όσες beta έχουν κυκλοφορήσει έως τώρα πάντως δεν το έχουν.
    Θα κάνω μια ερώτηση αν μπορούν η τέλος πάντων αν μπορεί να γίνει wizard με γραφικό περιβάλλον στο ER-X.

  11. #11
    Εγγραφή
    05-09-2014
    Μηνύματα
    426
    Downloads
    1
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    100/11
    ISP
    Cosmote
    DSLAM
    ΟΤΕ - ΔΑΦΝΗ
    Router
    EdgeRouter X
    SNR / Attn
    11(dB) / 11(dB)
    Path Level
    Interleaved
    Παράθεση Αρχικό μήνυμα από Knomax Εμφάνιση μηνυμάτων
    CRC δεν έχω στο modem..το ER-X λένε είναι οκ μέχρι τα 200Mbps αλλά μάλλον είναι πολύ αισιόδοξοι,θα συμφωνήσω μαζί σου..λιγότερο όριο έχει.
    Εδώ μετά βίας θα δεις Inter-VLAN Traffic να περνάει τα 200 Mbps με το hwnat κλειστό, στο QoS περιμένεις να δεις 200 Mbps;

    Παράθεση Αρχικό μήνυμα από Knomax Εμφάνιση μηνυμάτων
    Είναι μανούρα όπως λες....στις beta που παρακολουθώ..κουβέντα δεν γίνεται αν θα έχει το Cake..όσες beta έχουν κυκλοφορήσει έως τώρα πάντως δεν το έχουν.
    Θα κάνω μια ερώτηση αν μπορούν η τέλος πάντων αν μπορεί να γίνει wizard με γραφικό περιβάλλον στο ER-X.
    Ένα-ένα, δεν έχουν ακόμη βάλει ούτε το Dynamic DNS στα V2 Beta τους.

    Υπάρχει ήδη στο EdgeMAX Feature Requests / Suggestions αλλά δεν το έχουν δεχτεί (ακόμη τουλάχιστον).
    Μην το περιμένεις να έρθει σύντομα, έχουν δουλειά μπροστά τους μιας και αναβαθμίζουν σε νεότερο Kernel και αναβαθμίζουν και τα Packages.

  12. #12
    Εγγραφή
    05-11-2004
    Ηλικία
    33
    Μηνύματα
    3.739
    Downloads
    44
    Uploads
    0
    Άρθρα
    30
    Τύπος
    FTTH
    Ταχύτητα
    200/200 Mbps
    ISP
    Inalan
    Router
    EdgeRouter™ X
    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    QoS στο Down, όχι, δεν έχει νόημα, μιας και το πακέτο είναι ήδη "στην πόρτα σου".

    Η διαφορά μας είναι ότι βάζουμε Bandwidth Limit πιο κάτω απ' ό,τι περνάει από τη γραμμή για να σταματήσει να μαζεύεται Traffic στους Buffers του ISP.
    Αν ΔΕΝ βάλεις κάποιον Queue Manager όμως, το αποτέλεσμα θα είναι το ίδιο με αυτό που κάνει ο ISP. Όλα τα πακέτα μαζεύονται σε έναν κουβά και αρχίζει και κάνει Dequeue με τη σειρά που ήρθαν, ενώ συνεχίζει και κάνει Drop τα υπόλοιπα όσο το Inbound Traffic ξεπερνά το Limit στον Shaper.
    Μόνο αν υπήρχε κάποιος τρόπος να φροντίσεις να περάσουν τα μικρά πακέτα μπροστά παρά να μείνουν πίσω στην Queue...

    Αυτό ακριβώς κάνει ο Cake. Κρατάει έναν πολύ μικρό Buffer και ξεχωρίζει σε Flows τα διάφορα Streams.
    Την ώρα του Congestion στη μεριά σου (εφόσον έβαλες Limit για τον λόγο που είπα παραπάνω), τότε βλέπει ότι μαζεύει πακέτα στους Buffers που δημιούργησε το Bandwidth Limit και αποφασίζει να κάνει Drop/Mark τα Flows που κάνουν μονοπώλιο.


    Γι' αυτό τον λόγο έχει ενεργό το ECN by default στο Downstream.
    Το πακέτο έχει έρθει ήδη στο Router, αντί να το κάνει Drop και να ξαναπεράσει δεύτερη φορά αργότερα, απλά το δίνει στον παραλήπτη με ECN flag.
    Ακριβώς.

    Μου φαίνεται πάρα πολύ περίεργο που είναι δύσκολο στην κατανόηση αυτό το concept

    Η συντριπτική πλειοψηφία είναι χωρισμένη σε 2 groups: 1)Το group που δεν μπορεί να αντιληφθεί το οτι δεν έχει καμία χρήση το παραδοσιακό QoS στο downstream 2) Το group που μπορεί να αντιληφθεί το 1) αλλά δεν καταλαβαίνει οτι υπάρχει και η περίπτωση που θες να κάνεις bypass τον traffic shaper του upstream provider σου (ISP) και να το χειριστείς εσύ, δημιουργόντας downstream limit

    Γιατί να "ρουφάω" τα 200ms bufferbloat του ISP traffic shaper όταν το downstream της VDSL μου είναι 100% utilized? Κάνε drop αυτά που δεν έχουν "priority", δίνοντας μου λιγότερο από 100% downstream ως αποτέλεσμα, αλλά με 0ms bufferbloat
    OK boomer

  13. #13
    Εγγραφή
    05-09-2014
    Μηνύματα
    426
    Downloads
    1
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    100/11
    ISP
    Cosmote
    DSLAM
    ΟΤΕ - ΔΑΦΝΗ
    Router
    EdgeRouter X
    SNR / Attn
    11(dB) / 11(dB)
    Path Level
    Interleaved
    Παράθεση Αρχικό μήνυμα από globalnoise Εμφάνιση μηνυμάτων
    Ακριβώς.

    Μου φαίνεται πάρα πολύ περίεργο που είναι δύσκολο στην κατανόηση αυτό το concept

    Η συντριπτική πλειοψηφία είναι χωρισμένη σε 2 groups: 1)Το group που δεν μπορεί να αντιληφθεί το οτι δεν έχει καμία χρήση το παραδοσιακό QoS στο downstream 2) Το group που μπορεί να αντιληφθεί το 1) αλλά δεν καταλαβαίνει οτι υπάρχει και η περίπτωση που θες να κάνεις bypass τον traffic shaper του upstream provider σου (ISP) και να το χειριστείς εσύ, δημιουργόντας downstream limit

    Γιατί να "ρουφάω" τα 200ms bufferbloat του ISP traffic shaper όταν το downstream της VDSL μου είναι 100% utilized? Κάνε drop αυτά που δεν έχουν "priority", δίνοντας μου λιγότερο από 100% downstream ως αποτέλεσμα, αλλά με 0ms bufferbloat
    Για να είμαστε δίκαιοι, να πούμε ότι αυτό δουλεύει μόνο σε TCP και όχι σε UDP/ICMP, μιας και εκεί δεν έχεις τρόπο να κόψεις το traffic.
    Εκεί ναι, δεν μπορείς να κάνεις QoS στο Down, το μόνο που μπορείς να κάνεις είναι να το αναγνωρίζεις ότι υπάρχει και να περιορίσεις όλα τα υπόλοιπα ώστε να πέσεις πάλι κάτω από το όριο που έχεις θέσει στον Shaper, αλλιώς είναι χαμένο παιχνίδι.

    Δες το σαν να προσπαθείς να αποφύγεις το DDoS, δεν θα τα καταφέρεις αν δεν έχεις τρόπο να πεις "STOP" στην απέναντι μεριά.

  14. #14
    Εγγραφή
    05-11-2004
    Ηλικία
    33
    Μηνύματα
    3.739
    Downloads
    44
    Uploads
    0
    Άρθρα
    30
    Τύπος
    FTTH
    Ταχύτητα
    200/200 Mbps
    ISP
    Inalan
    Router
    EdgeRouter™ X
    Παράθεση Αρχικό μήνυμα από NinjaMiltos Εμφάνιση μηνυμάτων
    Για να είμαστε δίκαιοι, να πούμε ότι αυτό δουλεύει μόνο σε TCP και όχι σε UDP/ICMP, μιας και εκεί δεν έχεις τρόπο να κόψεις το traffic.
    Εκεί ναι, δεν μπορείς να κάνεις QoS στο Down, το μόνο που μπορείς να κάνεις είναι να το αναγνωρίζεις ότι υπάρχει και να περιορίσεις όλα τα υπόλοιπα ώστε να πέσεις πάλι κάτω από το όριο που έχεις θέσει στον Shaper, αλλιώς είναι χαμένο παιχνίδι.

    Δες το σαν να προσπαθείς να αποφύγεις το DDoS, δεν θα τα καταφέρεις αν δεν έχεις τρόπο να πεις "STOP" στην απέναντι μεριά.
    Οφ κορς, αλλά ποιο traffic θα κάνει saturate τόσο πολύ το downstream (χωρίς να είναι DDoS attack) που δεν είναι TCP?
    OK boomer

  15. #15
    Εγγραφή
    05-09-2014
    Μηνύματα
    426
    Downloads
    1
    Uploads
    0
    Τύπος
    VDSL2
    Ταχύτητα
    100/11
    ISP
    Cosmote
    DSLAM
    ΟΤΕ - ΔΑΦΝΗ
    Router
    EdgeRouter X
    SNR / Attn
    11(dB) / 11(dB)
    Path Level
    Interleaved
    Παράθεση Αρχικό μήνυμα από globalnoise Εμφάνιση μηνυμάτων
    Οφ κορς, αλλά ποιο traffic θα κάνει saturate τόσο πολύ το downstream (χωρίς να είναι DDoS attack) που δεν είναι TCP?
    Σε home environment, δεν μου έρχεται κάτι.
    Σε business environment, θα μπορούσε να είναι κάποιο τηλεφωνικό κέντρο αλλά και εκεί μου φαίνεται απίθανο να είναι τσίμα-τσίμα το bandwidth, θα ήταν ξεφτίλα. Ίσως και μερικά video conferences? Πάλι λίγο δύσκολο αλλά πρέπει να αναφερθούμε έστω και σε αυτή τη περίπτωση.

Σελ. 1 από 2 12 ΤελευταίαΤελευταία

Παρόμοια Θέματα

  1. [Other] Οδηγός QoS για Speedport Entry 2i - ZTE H268 - και άλλα ZTE modem/routers
    Από globalnoise στο φόρουμ ADSL & Broadband Hardware, routers και modems...
    Μηνύματα: 44
    Τελευταίο Μήνυμα: 29-01-21, 20:54
  2. [Other] Ubiquiti Edgerouter σε bridged mode
    Από Lewis στο φόρουμ ADSL & Broadband Hardware, routers και modems...
    Μηνύματα: 22
    Τελευταίο Μήνυμα: 16-11-20, 01:46
  3. Recovery φωτογραφιων σε Iphone X
    Από eDgE44 στο φόρουμ iOS
    Μηνύματα: 2
    Τελευταίο Μήνυμα: 22-02-19, 10:13
  4. Μηνύματα: 87
    Τελευταίο Μήνυμα: 29-10-18, 19:17
  5. [Other] edgerouter x setup
    Από christario2014 στο φόρουμ ADSL & Broadband Hardware, routers και modems...
    Μηνύματα: 9
    Τελευταίο Μήνυμα: 16-12-17, 21:31

Bookmarks

Bookmarks

Δικαιώματα - Επιλογές

  • Δεν μπορείτε να δημοσιεύσετε νέα θέματα
  • Δεν μπορείτε να δημοσιεύσετε νέα μηνύματα
  • Δεν μπορείτε να αναρτήσετε συνημμένα
  • Δεν μπορείτε να επεξεργαστείτε τα μηνύματα σας
  •  
  • Τα BB code είναι σε λειτουργία
  • Τα Smilies είναι σε λειτουργία
  • Το [IMG] είναι σε λειτουργία
  • Το [VIDEO] είναι σε λειτουργία
  • Το HTML είναι εκτός λειτουργίας