Οδηγός QoS για Speedport Entry 2i - ZTE H268 - και άλλα ZTE modem/routers

[globalnoise]

Χαιρετώ την κοινότητα που από το 2004, 14 χρονών, με εκπαιδεύει και με κάνει trigger.

Ο οδηγός αυτός έχει γραφτεί με βάση το Speedport Entry 2i του ομίλου ΟΤΕ. Πρόκειτε για μοντέλο της ZTE συνεπώς το interface και οι κανόνες αφορούν λίγο-πολύ και τα υπόλοιπα μοντέλα της ZTE όπως τα H108NS, H108L, H168N κλπ

Once again: Μην απενεργοποιείτε το QoS όταν έχετε τη συσκευή με active routing connection. Αυτό θα δημιουργήσει saturation, το VoIP θα είναι άχρηστο (το οποίο έχει δικό του, κρυφό rule). Με αποκλειστικά Bridge connection βέβαια κανένα πρόβλημα το QoS να είναι off.

Όπως προείπαμε, το QoS εφαρμόζεται στα εξής interfaces: WAN, LAN1, LAN2, LAN3, LAN4. Μιλάμε πάντα για uplink. Το QoS εφαρμόζεται στο uplink. Μια καλή ανάλυση εδώ. Δυστυχώς το Speedport (και όλα τα ZTE) δεν παρέχουν κάποιου είδους ACK delaying για να μπορέσουμε να έχουμε downstream bandwidth throttling.

Traffic Shaping vs Traffic Policing. Περισσότερα εδώ. By default, το Speedport (και όλα τα ZTE) πραγματοποιεί traffic shaping σε όλα τα uplinks σύμφωνα με το bitrate του PHY. Αν θέλουμε να είμαστε σίγουροι (αν και δεν βρήκα διαφορά στην συμπεριφορά) μπορούμε να θέσουμε το bitrate ένα κλικ κάτω από το max throughput (που το βρίσκουμε κάνοντας saturate το uplink και μειώνοντας σιγά σιγά στο bitrate). Στην περίπτωση COSMOTE VDSL με 5Mbps upload π.χ. είναι αυτό:



Traffic shaping = buffered data = bufferbloat. Ευτυχώς δεν είναι κακώς ρυθμισμένο στο Speedport, μπορείτε να το τεστάρετε στο dslreports.com/speedtest (με Ethernet και όχι WiFi που έχει extra buffers αλλά και πάλι είναι αποδεκτοί οι χρόνοι). Αυτό σημαίνει οτι είναι σχεδόν κομπλέ για realtime use cases ακόμα και σε saturated uplink στιγμές.

Αν πάλι για κάποιο λόγο θέλετε να έχετε μηδενικό upstream bufferbloat (στο downstream είπαμε δεν έχουμε έλεγχο, εκτός αν αποκτήσουμε πρόσβαση στον BBRAS της COSMOTE) στην καρτέλα Traffic Policing θέτουμε το αντίστοιχο rule. Θέτοντας όριο bitrate και non-conforming action -> Drop, οποιοδήποτε πακέτο που δεν κάνει conform το rule γίνεται drop και δεν φτάνει ποτέ τον buffer του Traffic Shaper. Για το πως θα ορίσετε applications/devices στο rule αυτό διαβάστε τη συνέχεια.

Classification. Το classification στο Speedport Entry 2i γίνεται με βάση το WAN interface. Σε άλλα ZTE, το classification μπορεί να γίνεται με βάση όλα τα interfaces που είναι ενεργό το QoS. Συνεπώς, τα source και destination πεδία αφορούν τα uplinks (θα το πω πολλές φορές για χάρη ενός γερομάστορα που μου χάρισε άπειρες μέρες αισχρού internet quality με τις ατεκμηρίωτες συμβουλές του) αυτών των interfaces. Source θεωρείται οτι είναι πριν το uplink και destination οτι είναι μετά (προφανώς). "In layman's terms", αφού μας νοιάζει και μας καίει το WAN interface στο Speedport Entry 2i, source θεωρείται οτιδήποτε στο LAN μας και destination οτιδήποτε στο WAN (Internet). Δεν θέτουμε destination του τοπικού μας δικτύου, εκτός αν το ZTE μας μπορεί να κάνει classify σε interface πέραν του WAN[1].

Ιδιέταιρη σκέψη θέλει και το classification priority, καθώς πρέπει να σκεφτούμε τι μας ενδιαφέρει να γίνεται classify πρώτα, όταν ένα traffic κάνει apply σε περισσότερα από 1 classifications.

Με βάση αυτά, σας παρουσιάζω το δικό μου setup για καλύτερη κατανόηση. Στο διαμέρισμα υπάρχουν 2 laptop, 2 smartphone, 1 PS4 με Twitch streaming και 1 Smart TV.

Ο σκοπός είναι: Always responsive web browsing, always responsive PS4 online gaming, RTPM (Twitch) streaming με bandwidth throttling για να μην δημιουργεί bufferbloat, always responsive Smart TV.

Classification για Smart TV. Χρησιμοποίησα το υπάρχον classification του OTE για την TV του μιας και δεν έχω και άλλαξα το ingress interface σε all αντί για LAN4 και σέταρα την mac address της Samsung μου. Τα remarkings τα άφησα όπως ήταν για την OTETV. Ποτέ δεν ξέρεις, μπορεί να τους δίνουν priority. Του έβαλα ένα traffic class για να το χώσω στο queing μετά:



Classification για Twitch streaming (RTMP). Το Twitch χρησιμοποιεί RTMP το οποίο είναι TCP based στη θύρα 1395. Αυτό βοηθάει γιατί βάζοντας μετά Rate στο queue του για να μην δημιουργεί bufferbloat, το TCP stream κάνει adapt και δημιουργεί steady bitrate. Του έβαλα ένα traffic class για να το χώσω στο queing μετά:



Classification για PS4. Το twitch stream στην 1395 που είπα πριν πηγάζει από αυτό το PS4. Είναι λοιπόν σημαντικό το twitch stream να γίνει classify πριν το PS4 γιατί μετά άκυρο το classification του, θα το είχε τσιμπήσει το classification του PS4 και θα ήταν 1 traffic class όλο μαζί. Το PS4 μου το έχω στην LAN1 μόνο του οπότε αρκεί αυτό για classify (θεωρητικά (lol.. who knows) είναι και πιο γρήγορο σε σχέση με το να του έβαζα MAC address) Once again, του έβαλα ένα traffic class για να το χώσω στο queing μετά:



Classification για ICMP, UDP/TCP DNS (port 53), TCP ACK. Τα πακέτα αυτά θέλω να έχουν το highest priority στον buffer του traffic shaper. Once again, τους έβαλα ένα κοινό traffic class για να τα χώσω στο queing μετά:



Προσοχή στη δημιουργία και διαγραφή των classifications. Έχω παρατηρήσει bug που μετά από delete ορίζει ίδιο classification priority σε 2 διαφορετικά entries. Σταματάει να δουλεύει σωστά και θέλει reset από το κουμπί

Traffic Policing Rule Index. Όπως είπαμε πριν, αν θέλουμε να πραγματοποιήσουμε traffic policing σε κάποιο από αυτά τα traffics, το ορίζουμε σε αυτήν την επιλογή του classification

Στο Congestion Management, δημιουργούμε τα queues, με τα priorities που θέλουμε και προσωπικά, χρησιμοποιώντας SP algorithm για simplicity. Πάντα δημιουργούμε ένα queue με default priority on και θέτουμε κατα προτίμιση το lowest priority value. Είναι το queue για όλο το non-classified traffic.

Εδώ αξίζει να αναφέρω το queue για το Twitch stream (RTMP TCP 1395) που θέτοντας Rate μπορώ να το αποτρέψω από το να δημιουργήσει bufferbloat στο uplink. Σημαντικό για το online gaming που πραγματοποιείται την ίδια ώρα. Με αυτό τον τρόπο έχω καταφέρει το additional latency με ταυτόχρονο streaming να είναι +2 εως +5 ms, όταν χωρίς αυτό κυμαίνεται στο +15. Μια σημείωση για την περίπτωση χρήσης Traffic Policing για rate limiting. Επειδή τα packets γίνονται drop, to Twitch κάνει adapt το TCP stream σε bitrate αρκετά χαμηλότερο από αυτό του ορίου, έχοντας ως αποτέλεσμα σημαντικό downgrade στο video quality. Θέτοντας το Rate στο queue, στην ουσία είναι ένας 2ος traffic shaper με δικό του buffer, κρατόντας το traffic throughput στο Rate που του έχουμε θέσει. Στην προκειμένη, 4 Mbps, adequate για το 720p60 stream μου:



Η λειτουργία των queues με στατιστικά:



Με το παρόν setup, όταν το laptop ή κάποιο smartphone κάνει upload/download δεν επηρεάζονται σε unusable βαθμό τα: Web Browsing, PS4 gaming, Twitch Streaming, Smart TV video. Αντίστοιχα, όταν για παράδειγμα υπάρχει ένα twitch stream ενεργό, το upload των laptop/smartphones επηρεάζεται πέρνοντας μικρότερο priority, και αυτό είναι και το ζητούμενο.

Δυστυχώς, χωρίς downstream bandwidth throttling (λόγω έλλειψης παροχής ACK delaying ή Smart QoS fq_codel κλπ) όταν κάποιος client κάνει saturate το downstream, το bufferbloat (από τη μεριά του ISP) επηρεάζει τα realtime applications. Δεν μπορούμε να κάνουμε κάτι για αυτό πέρα από ρυθμίσεις π.χ. στα Torrent apps. Βέβαια...[1]

[1] Θεωρητικά, για όποιο ZTE επιτρέπει classification σε όλα τα interfaces, μπορούμε συνδέοντας μια συσκευή στο LAN2 για παράδειγμα, να δημιουργήσουμε classification για traffic από το WAN με destination applications/devices στην LAN2. Δημιουργούμε queue στο LAN2 interface (by default δεν έχει κανένα) και ορίζουμε priorities/rate limiting ή/και traffic policing. Στο Speedport Entry 2i μπορούμε να δημιουργήσουμε traffic shaping rule για όλο το LAN2 interface από την αντίστοιχη καρτέλα, θέτοντας downstream (από το internet) bandwidth limit για όλες τις συσκευές που είναι συνδεδεμένες στην LAN2. Χρειάζεται η δημιουργία μιας default queue στο Congestion Management για να λειτουργήσει αυτό. Δυστυχώς, η ίδια δυνατότητα δεν υπάρχει για τα WLAN SSIDs.

That's all folks.

[NinjaMiltos]

Ενδιαφέρον οδηγός.

Η πόρτα που κάνει Stream προς το Twitch είναι πάντα η Destination TCP 1395, έτσι;
Με ενδιαφέρει διότι και εγώ για να κάνω Stream, περνάω πρώτα μέσω Remote Play, το παίρνω με το OBS, κάνω DSCP mark το traffic του OBS και έχω έτοιμο rule μόλις βλέπει DSCP 24 από το 192.168.1.0/24, να δίνει guaranteed bandwidth για να μην έχω dropped frames.
Αν μπορώ να καταφέρω να μαρκάρω το Stream από την κονσόλα, τότε θα με βοηθήσει αρκετά να μην έχω dropped frames όταν κάνω Stream απ' ευθείας από την κονσόλα.

Όσο για το bufferbloat, τα πράγματα είναι πολύ καλύτερα στις VDSL (Λόγο bandwidth; Λόγο καλύτερα ρυθμισμένου εξοπλισμού; ).
Αναφέρομαι στο Downstream. Το bufferbloat δεν είναι τραγικό όπως είναι ακόμη στις ADSL και αυτό είναι το πρόβλημα στους περισσότερους.
Άνοιξες YouTube; ping.
Στις VDSL όμως έχεις Packet Loss αντί για Bufferbloat. Το βέλτιστο θα ήταν να μην υπήρχε κάποιο από τα δύο, κάνοντας χρήση κάποιου SQM στο Downstream από την μεριά των ISP αλλά γιατί να το κάνουν; "Upgrade σε μεγαλύτερο πακέτο με την ελπίδα να σταματήσεις να βαράς τους buffers στο Down".
Θα μπορούσε να το διαφημίσει ο ΟΤΕ (ή όποιος άλλος έχει χρήμα για Hardware) ως "Η καλύτερη εμπειρία στο Internet από πότε, ακόμη και αν ο συγκάτοικος αποφάσισε να κατεβάσει ολόκληρο το Internet" ή "Online Gaming όπως ποτέ, δίχως lags, ανεξάρτητα από τον φόρτο της γραμμής".
Nah...

Τώρα για το Upload, είδα ότι έχει περίπου +100ms με +150ms bufferbloat στην 50ρα.
Στις ADSL πάλι, απλά δεν... Πονεμένη ιστορία.

Για την διαφορά του ADSL από ΑΚ με το ADSL μέσω KV, αναφέρθηκα εδώ και τα πράγματα είναι απλά τραγικά.
Όσοι είναι σε ADSL από ΑΚ, τείνουν να έχουν μεγάλο θέμα με bufferbloat στο Down, ενώ αν πάρουν υπηρεσία ADSL μέσω καινούριου εξοπλισμού, συνήθως τα πράγματα είναι όπως στις VDSL.
Τραγικό.

[globalnoise]

Ενδιαφέρον οδηγός.

Η πόρτα που κάνει Stream προς το Twitch είναι πάντα η Destination TCP 1395, έτσι;
Με ενδιαφέρει διότι και εγώ για να κάνω Stream, περνάω πρώτα μέσω Remote Play, το παίρνω με το OBS, κάνω DSCP mark το traffic του OBS και έχω έτοιμο rule μόλις βλέπει DSCP 24 από το 192.168.1.0/24, να δίνει guaranteed bandwidth για να μην έχω dropped frames.
Αν μπορώ να καταφέρω να μαρκάρω το Stream από την κονσόλα, τότε θα με βοηθήσει αρκετά να μην έχω dropped frames όταν κάνω Stream απ' ευθείας από την κονσόλα.

Ναι, είναι πάντα η TCP 1395

Όσο για το bufferbloat, τα πράγματα είναι πολύ καλύτερα στις VDSL (Λόγο bandwidth; Λόγο καλύτερα ρυθμισμένου εξοπλισμού; ).
Αναφέρομαι στο Downstream. Το bufferbloat δεν είναι τραγικό όπως είναι ακόμη στις ADSL και αυτό είναι το πρόβλημα στους περισσότερους.
Άνοιξες YouTube; ping.
Στις VDSL όμως έχεις Packet Loss αντί για Bufferbloat. Το βέλτιστο θα ήταν να μην υπήρχε κάποιο από τα δύο, κάνοντας χρήση κάποιου SQM στο Downstream από την μεριά των ISP αλλά γιατί να το κάνουν; "Upgrade σε μεγαλύτερο πακέτο με την ελπίδα να σταματήσεις να βαράς τους buffers στο Down".
Θα μπορούσε να το διαφημίσει ο ΟΤΕ (ή όποιος άλλος έχει χρήμα για Hardware) ως "Η καλύτερη εμπειρία στο Internet από πότε, ακόμη και αν ο συγκάτοικος αποφάσισε να κατεβάσει ολόκληρο το Internet" ή "Online Gaming όπως ποτέ, δίχως lags, ανεξάρτητα από τον φόρτο της γραμμής".
Nah...

Παίζει τέτοιο θέμα στις ADSL ε; Χμμμ.. δεν αποκλείεται να είναι λόγω hardware. Εκτός αν οι κάρτες των DSLAM για τις ADSL πόρτες είναι οι ίδιες με των VDSL, που το αποκλείω γιατί υπάρχει καθυστέρηση στην μετάβαση από την μία υπηρεσία στην άλλη. Στους υπόλοιπους παρόχους τι παίζει με το θέμα του bufferbloat στο downstream?

SQM στο Downstream από την μεριά των ISP μου φαίνεται ακραίο σε HW requirement. Υπάρχει άραγε ISP σε παγκόσμιο επίπεδο που το κάνει;

Όλα αυτά που περιέγραψες marketing-wise τα έχουν χρησιμοποιήσει για την VDSL (η COSMOTE σίγουρα) και σε τηλεοπτικά σποτ μάλιστα.

Τώρα για το Upload, είδα ότι έχει περίπου +100ms με +150ms bufferbloat στην 50ρα.
Στις ADSL πάλι, απλά δεν... Πονεμένη ιστορία.

Στις ADSL με ίδιο CPE δεν θα 'πρεπε να υπάρχει διαφορά. Υπάρχει; Αν ναι, σε Speedport π.χ. με Traffic shaping ενεργό είναι μεγαλύτερο το bufferbloat? Θα μου φανεί περίεργο αν είναι. Επίσης με traffic policing και drop πριν τον buffer μπορεί να μηδενιστεί και στην ADSL.

- - - Updated - - -

Με το τεστ που έκανα κάνοντας Traffic Shaping στο 90% του VDSL downstream bitrate σε LAN θύρα, παρουσιάστηκε βελτιωμένο downstream bufferbloat, καθώς πλέον το buffering γίνεται στον traffic shaper του Speedport. Το αποτέλεσμα; ~20ms bufferbloat σε σχέση με τα ~50 χωρίς. Φυσικά με τους περιορισμούς της εφαρμογής του limit αυτού σε Ethernet LAN θύρα only.

[NinjaMiltos]

Παίζει τέτοιο θέμα στις ADSL ε; Χμμμ.. δεν αποκλείεται να είναι λόγω hardware. Εκτός αν οι κάρτες των DSLAM για τις ADSL πόρτες είναι οι ίδιες με των VDSL, που το αποκλείω γιατί υπάρχει καθυστέρηση στην μετάβαση από την μία υπηρεσία στην άλλη. Στους υπόλοιπους παρόχους τι παίζει με το θέμα του bufferbloat στο downstream?

Δεν ξέρω τι παίζει με τους υπόλοιπους παρόχους, δεν έχω δείγματα από όλους τους υπόλοιπους διότι οι περισσότεροι είναι στον OTE απ' αυτούς που γνωρίζω. Θα κοιτάξω να δω τι παίζει (αν ενδιαφερθεί κανείς να τρέξει το test και να μου το στείλει).

SQM στο Downstream από την μεριά των ISP μου φαίνεται ακραίο σε HW requirement. Υπάρχει άραγε ISP σε παγκόσμιο επίπεδο που το κάνει;

Δεν μπορείς να το κάνεις αλλιώς, πρέπει να περάσει μέσω του linux kernel και αν θέλεις να κάνεις χρήση του fq_codel, sch_cake ή fq_pie σε σοβαρό bandwidth, θες και σοβαρό hardware.
Έχω κάνει compile τον sch_cake σε Ubuntu 17.10 αλλά δεν δοκίμασα να δω τι επεξεργαστική ισχύ χρειάζεται σε Gigabit, το δοκίμασα μόνο πάνω στην 50ρα μιας και αυτό με έκαιγε εκείνη τη στιγμή.
Ίσως κάτσω να το δω κάποια στιγμή μεταξύ δύο Virtual Machine.

Anyway, τελευταία παράγραφος.
https://www.bufferbloat.net/projects...ue_Management/

Όλα αυτά που περιέγραψες marketing-wise τα έχουν χρησιμοποιήσει για την VDSL (η COSMOTE σίγουρα) και σε τηλεοπτικά σποτ μάλιστα.

Το πρόβλημα στο Down με το Packet Loss παραμένει όμως. Σίγουρα είναι πολύ καλύτερα από τα τετραψήφια pings που έβλεπα στο ADSL αλλά πρόβλημα σίγουρα υπάρχει, άλλου είδους αυτή τη στιγμή όμως. Ευτυχώς όμως όχι τόσο σοβαρό.

Το Up είναι ακόμα για τα πανηγύρια. Ειλικρινά πιστεύουν ότι ο κόσμος θα αναβαθμίζει συνέχεια για να έχει όλο και περισσότερο Upload Bandwidth ώστε να σταματήσει να βαράει τους buffers ή έστω να είναι το bufferbloat σε "αποδεκτά" επίπεδα;
Θα ήθελα πολύ να δω μερικά tests από την 100ρα, πόσο μάλλον από την 200ρα όπου θα είναι σχεδόν ανύπαρκτο το bufferbloat λόγο του ότι αδειάζει γρηγορότερα τους buffers;

Με το τεστ που έκανα κάνοντας Traffic Shaping στο 90% του VDSL downstream bitrate σε LAN θύρα, παρουσιάστηκε βελτιωμένο downstream bufferbloat, καθώς πλέον το buffering γίνεται στον traffic shaper του Speedport. Το αποτέλεσμα; ~20ms bufferbloat σε σχέση με τα ~50 χωρίς. Φυσικά με τους περιορισμούς της εφαρμογής του limit αυτού σε Ethernet LAN θύρα only.

Δοκίμασες κάποιο ακραίο limit όπως 50% αντί για 90%; Το bufferbloat παραμένει στα 20ms; Προσπαθώ να καταλάβω αν πλέον είναι buffer στο Speedport ή από τη δική τους μεριά.
Επίσης δοκίμασες με WFQ αντί για SP;

Θεωρητικά αν κάνεις limit μια LAN θύρα, δεν θα πάρει μπάλα και το LAN-to-LAN traffic; Ή λες να την γλυτώσει αν είναι switched (layer 2) οι πόρτες του και δεν προλαβαίνουν να μπουν στον shaper;

Κάτι παράξενο επίσης, γύρισα το default queue (το 8 νομίζω είναι) από SP σε WFQ και παρατήρησα τα εξής κουφά.
1) Αντί να είναι το "Queue 8" και να συνεχίζω να βλέπω traffic εκεί όπως το βλέπω με το SP, πλέον είναι ως "Queue 1" χωρίς να αλλάξω κάτι άλλο.
2) Είχα χαμηλότερο bufferbloat στο Up (από 120ms σε 60-80ms νομίζω, πρέπει να το ξαναδώ).

Δοκιμή πιστεύω πρέπει να γίνει επίσης με το QoS όπως είναι out-of-the-box και να γίνει toggle on/off.
Επίσης δοκιμή με WFQ αντί για SP (αν και ο SP φαίνεται να είναι καλύτερος γιατί Drop-άρει απευθείας αντί να χρησιμοποιεί βάρη; )

[globalnoise]

Το Up είναι ακόμα για τα πανηγύρια. Ειλικρινά πιστεύουν ότι ο κόσμος θα αναβαθμίζει συνέχεια για να έχει όλο και περισσότερο Upload Bandwidth ώστε να σταματήσει να βαράει τους buffers ή έστω να είναι το bufferbloat σε "αποδεκτά" επίπεδα;
Θα ήθελα πολύ να δω μερικά tests από την 100ρα, πόσο μάλλον από την 200ρα όπου θα είναι σχεδόν ανύπαρκτο το bufferbloat λόγο του ότι αδειάζει γρηγορότερα τους buffers;

Για το bufferbloat στο Up ευθήνη έχει καθαρά το CPE. Αν ο buffer του είναι ρυθμισμένος να bufferιάζει 5ms, 5ms θα είναι το bufferbloat. Αν δεν περνάει buffer και κάνει drop (traffic policing) θα έχει 0ms bufferbloat. Στην προκειμένη όντως όσο περιορίζεις το Rate τόσο πιο πολύ είναι το bufferbloat. Btw στα 100 είναι 10 και στα 200 είναι 20 το upload, δηλαδή όχι και τίποτα abundant

Δοκίμασες κάποιο ακραίο limit όπως 50% αντί για 90%; Το bufferbloat παραμένει στα 20ms; Προσπαθώ να καταλάβω αν πλέον είναι buffer στο Speedport ή από τη δική τους μεριά.
Επίσης δοκίμασες με WFQ αντί για SP;

Δοκίμασα με 15Mbps (πάνω από 50% δλδ) και ήταν 20. Με 95% ήταν όντως σχεδόν 0. Χμμ δεν ξέρω αν είναι σωστό να το σκέφτεσαι έτσι. Οι buffers γεμίζουν στον traffic shaper που θα ενεργοποιηθεί πρώτος. Στην περίπτωση του 90% και 50% setting ο shaper του ISP δεν ενεργοποιείται γιατί υπάρχει 10% και 50% extra available bandwidth πριν ξεκινήσει το buffering. Αυτό σημαίνει οτι το 20ms αυτό είναι το buffering του shaper του Speedport. Αν απενεργοποιήσω τον shaper αυτόν θα ενεργοποιείται ο shaper του ISP γιατί θα φτάσει στο 100% του available downstream bandwidth. Μόνο του ISP όμως, ο shaper του Speedport χωρίς ρύθμιση, για να ενεργοποιηθεί και αυτός πρέπει να μου σκάσουν 100+Mbps downstream.

Θεωρητικά αν κάνεις limit μια LAN θύρα, δεν θα πάρει μπάλα και το LAN-to-LAN traffic; Ή λες να την γλυτώσει αν είναι switched (layer 2) οι πόρτες του και δεν προλαβαίνουν να μπουν στον shaper;

Δεν μπορώ να το δοκιμάσω (δεν έχω clients) αλλά είμαι αρκετά σίγουρος οτι θα το πάρει η μπάλα για τον λόγο ακριβώς που αναφέρεις. Ο shaper είναι στο switch level. Και αυτός είναι και ο λόγος που δεν μπορείς να κάνεις classify πακέτα με source το WAN και destination το LAN σου (δες τα edits στο original post μου, έκανα πειράματα). Μπορείς ξέρω γω να βάλεις destination mac address ενός SSID (tested, παθαίνει κοκομπλόκο το WLAN άμα το κάνεις). Επίσης WAN interface + LAN interfaces έχουν ίδιο MAC. Όλα αυτά είναι ενδείξεις οτι ο shaper είναι στο switch level. I mean, δεν έχω και το source code για να ξέρω τι έχουν κάνει αλλά θα έπαιζα στοίχημα οτι είναι έτσι.

Κάτι παράξενο επίσης, γύρισα το default queue (το 8 νομίζω είναι) από SP σε WFQ και παρατήρησα τα εξής κουφά.
1) Αντί να είναι το "Queue 8" και να συνεχίζω να βλέπω traffic εκεί όπως το βλέπω με το SP, πλέον είναι ως "Queue 1" χωρίς να αλλάξω κάτι άλλο.
2) Είχα χαμηλότερο bufferbloat στο Up (από 120ms σε 60-80ms νομίζω, πρέπει να το ξαναδώ).

3. If the algorithm is WFQ, scheduling policies will take effect only when the total weight of WFQ queues with same priority is 100%.

Του έβαλες 100 (ως μοναδικο queue με αυτό το priority level?); Αν όχι ψιλοmakes sense να πάει στην 1 γιατί:

4. There is a default queue in every interface. If not specified, the first queue will work as the default queue, otherwise, the last setting queue will be the default queue. Note that the default queue will automatically enabled and can not be disabled.

Δεν θα έπρεπε να δεις καμία διαφορά στο bufferbloat στο up. Ο traffic shaper παραμένει ίδιος, άρα και το buffer setting του. Να μειώνει το buffer setting του επειδή ένα ή περισσότερα queues είναι WFQ δεν μου φαίνεται πιθανό..

EDIT: Το δοκίμασα, ίδια bufferbloats πήρα, ανάλογα το rate. Κοντά στα 5Mbps (95%) πήρα τα γνωστά 100-120 και στο 50%, δηλαδή 2,5Mbps έφτασε και 200ms σε κάποιες στιγμές.

Προσοχή μη γίνονται αυτά μέσω WiFi που έχει δικό του buffer + bufferbloat extra

Δοκιμή πιστεύω πρέπει να γίνει επίσης με το QoS όπως είναι out-of-the-box και να γίνει toggle on/off.
Επίσης δοκιμή με WFQ αντί για SP (αν και ο SP φαίνεται να είναι καλύτερος γιατί Drop-άρει απευθείας αντί να χρησιμοποιεί βάρη; )

Με toggle off το expected θα είναι 0 bufferbloat στο Up λόγω ανύπαρκτου traffic shaping (θα το δοκιμάσω) και ότι bufferbloat έχει ο ISP ρυθμισμένο στον δικό του shaper στο downstream

Δεν νομίζω οτι υπάρχει διαφορά στο Strict Policy vs Weighted Fair Queueing στο buffer setting του shaper. Δες εδώ σελίδα 86 και σελίδα 88 Configuring Queue Bandwidth Limit. Αυτό μοιάζει να είναι το setting που αφορά την μεριά του ISP για bufferbloat (αν είχαν ZTE μηχανήματα)

Ε ρε που 'χουμε μπλέξει με τους Κινέζους

[NinjaMiltos]

Για το bufferbloat στο Up ευθήνη έχει καθαρά το CPE. Αν ο buffer του είναι ρυθμισμένος να bufferιάζει 5ms, 5ms θα είναι το bufferbloat. Αν δεν περνάει buffer και κάνει drop (traffic policing) θα έχει 0ms bufferbloat. Στην προκειμένη όντως όσο περιορίζεις το Rate τόσο πιο πολύ είναι το bufferbloat. Btw στα 100 είναι 10 και στα 200 είναι 20 το upload, δηλαδή όχι και τίποτα abundant

Έκανα έναν πρόχειρο υπολογισμό και βγάζω ότι ο Buffer του είναι γύρο στα 60KB.
Αν δεν το υπολογίσω με το Sync Speed και το υπολογίσω χωρίς το overhead του PTM (5% νομίζω), τότε πλησιάζει πολύ άσχημα στα 56KB.

Με τους ίδιους αριθμούς, αν πας στην "100ρα" και στην "200ρα", τότε το bufferbloat πέφτει στα 50ms και στα 25ms αντίστοιχα.
Διαφορά; Τεράστια. Πάλι τα 25ms μου φαίνονται κάπως αλλά και πάλι είναι φοβερή βελτίωση αν όντως αυτά είναι τα νούμερα.

Δεκτή κάθε διόρθωση αν το υπολογίζω λάθος.

Δοκίμασα με 15Mbps (πάνω από 50% δλδ) και ήταν 20. Με 95% ήταν όντως σχεδόν 0. Χμμ δεν ξέρω αν είναι σωστό να το σκέφτεσαι έτσι. Οι buffers γεμίζουν στον traffic shaper που θα ενεργοποιηθεί πρώτος. Στην περίπτωση του 90% και 50% setting ο shaper του ISP δεν ενεργοποιείται γιατί υπάρχει 10% και 50% extra available bandwidth πριν ξεκινήσει το buffering. Αυτό σημαίνει οτι το 20ms αυτό είναι το buffering του shaper του Speedport. Αν απενεργοποιήσω τον shaper αυτόν θα ενεργοποιείται ο shaper του ISP γιατί θα φτάσει στο 100% του available downstream bandwidth. Μόνο του ISP όμως, ο shaper του Speedport χωρίς ρύθμιση, για να ενεργοποιηθεί και αυτός πρέπει να μου σκάσουν 100+Mbps downstream.

Αυτό δεν το γνωρίζεις. Πάει ανάλογα το traffic που σου έρχεται και το πόσο γρήγορα ανταποκρίνεται ο αποστολέας όταν του στείλεις signal για congestion (ECN) ή για dropped packet (no ECN).

Παράδειγμα.
Αν βάλω ένα Speedtest, το eth0 με το pppoe0 στο ER-X και βάλω τον shaper στο pppoe0 που είναι μετά από το eth0 (πρώτα χτυπάει το traffic στο eth0 και μετά περνάει από το pppoe0), τότε η διαφορά μεταξύ τους είναι λιγότερη από 1 Mbps.
Αν βάλω όμως ένα torrent το οποίο δεν έχει limit στα connections και αρχίσουν και με βαράνε με όλων των ειδών το traffic, τότε η διαφορά μεταξύ αυτονών των δύο interfaces μεγαλώνει και πλησιάζει τα 1.5 με 2 Mbps.

Τι θέλω να πω με αυτό. Εννοώ ότι δεν μπορείς να έχεις πολύ κοντά στο Line Speed τον Shaper. Κάποια στιγμή θα υπερβεί το traffic το line speed και θα αρχίσεις να χτυπάς τους buffers στη μεριά του ISP. Μόνο αν ορίσεις ένα τέτοιο όριο ώστε σε καμία περίπτωση δεν βαράς buffers, ανεξαρτήτου traffic, μόνο τότε είσαι "OK".

3. If the algorithm is WFQ, scheduling policies will take effect only when the total weight of WFQ queues with same priority is 100%.

Του έβαλες 100 (ως μοναδικο queue με αυτό το priority level?); Αν όχι ψιλοmakes sense να πάει στην 1 γιατί:

4. There is a default queue in every interface. If not specified, the first queue will work as the default queue, otherwise, the last setting queue will be the default queue. Note that the default queue will automatically enabled and can not be disabled.

Δεν θα έπρεπε να δεις καμία διαφορά στο bufferbloat στο up. Ο traffic shaper παραμένει ίδιος, άρα και το buffer setting του. Να μειώνει το buffer setting του επειδή ένα ή περισσότερα queues είναι WFQ δεν μου φαίνεται πιθανό..

EDIT: Το δοκίμασα, ίδια bufferbloats πήρα, ανάλογα το rate. Κοντά στα 5Mbps (95%) πήρα τα γνωστά 100-120 και στο 50%, δηλαδή 2,5Mbps έφτασε και 200ms σε κάποιες στιγμές.

Προσοχή μη γίνονται αυτά μέσω WiFi που έχει δικό του buffer + bufferbloat extra

Το μόνο που έκανα ήταν να αλλάξω το default queue από SP σε WFQ και να του βάλω 10% Weight (just for giggles).
Δεν το άφησα να παίξει παραπάνω από μερικά λεπτά διότι είδα ότι από 8ο Queue έγινε 1ο και φοβήθηκα για το VoIP.

Θα το ξανακοιτάξω μαζί με το toggle στο QoS επίσης.

[globalnoise]

Έκανα έναν πρόχειρο υπολογισμό και βγάζω ότι ο Buffer του είναι γύρο στα 60KB.
Αν δεν το υπολογίσω με το Sync Speed και το υπολογίσω χωρίς το overhead του PTM (5% νομίζω), τότε πλησιάζει πολύ άσχημα στα 56KB.

Με τους ίδιους αριθμούς, αν πας στην "100ρα" και στην "200ρα", τότε το bufferbloat πέφτει στα 50ms και στα 25ms αντίστοιχα.
Διαφορά; Τεράστια. Πάλι τα 25ms μου φαίνονται κάπως αλλά και πάλι είναι φοβερή βελτίωση αν όντως αυτά είναι τα νούμερα.

Δεκτή κάθε διόρθωση αν το υπολογίζω λάθος.

Σωστός.. Makes sense ο υπολογισμός

Αυτό δεν το γνωρίζεις. Πάει ανάλογα το traffic που σου έρχεται και το πόσο γρήγορα ανταποκρίνεται ο αποστολέας όταν του στείλεις signal για congestion (ECN) ή για dropped packet (no ECN).

Παράδειγμα.
Αν βάλω ένα Speedtest, το eth0 με το pppoe0 στο ER-X και βάλω τον shaper στο pppoe0 που είναι μετά από το eth0 (πρώτα χτυπάει το traffic στο eth0 και μετά περνάει από το pppoe0), τότε η διαφορά μεταξύ τους είναι λιγότερη από 1 Mbps.
Αν βάλω όμως ένα torrent το οποίο δεν έχει limit στα connections και αρχίσουν και με βαράνε με όλων των ειδών το traffic, τότε η διαφορά μεταξύ αυτονών των δύο interfaces μεγαλώνει και πλησιάζει τα 1.5 με 2 Mbps.

Τι θέλω να πω με αυτό. Εννοώ ότι δεν μπορείς να έχεις πολύ κοντά στο Line Speed τον Shaper. Κάποια στιγμή θα υπερβεί το traffic το line speed και θα αρχίσεις να χτυπάς τους buffers στη μεριά του ISP. Μόνο αν ορίσεις ένα τέτοιο όριο ώστε σε καμία περίπτωση δεν βαράς buffers, ανεξαρτήτου traffic, μόνο τότε είσαι "OK".

Χμμ, η διαφορά μεγαλώνει επειδή αυξάνεται το receiving rate στο eth0 και παραμένει σταθερή στο pppoe0? Τότε σωστά makes sense αυτό που λες με πολλά connections. Είμαστε δηλαδή στο έλεος της ρύθμισης του shaper στο interface του ISP.

Το μόνο που έκανα ήταν να αλλάξω το default queue από SP σε WFQ και να του βάλω 10% Weight (just for giggles).
Δεν το άφησα να παίξει παραπάνω από μερικά λεπτά διότι είδα ότι από 8ο Queue έγινε 1ο και φοβήθηκα για το VoIP.

Θα το ξανακοιτάξω μαζί με το toggle στο QoS επίσης.

Αν τα weights του priority συνολικά δεν είναι 100 δεν ενεργοποιείται. Γιαυτό τα πήγαινε στο 1ο.

Κάποια στιγμή χθες το δοκίμασα με QoS off και δεν είδα κάποια διαφορά. Νομίζω οτι παραμένει ο shaper ενεργός στο interface και με QoS off απλά με default queue, χωρίς classification κλπ

- - - Updated - - -

Test στη δουλειά με Forthnet VDSL 30, Modem/router Technicolor TG788vn v2

Μηδενικό bufferbloat στο down.. Τεράστιο στο up http://www.dslreports.com/speedtest/29647372

[MatthewMethod]

Ρε παλικάρι τι μας γράφεις πάνω πάνω ότι το Qos πιάνει μόνο στο uplink; Και λέω γιατί γ@!#@ι το σύμπαν. Ότι ρύθμιση βάζω πιάνει και στο downlink και στο uplink και κατάφερα να το κάνω να έχω 2 από 30 Mbps...

[globalnoise]

Ρε παλικάρι τι μας γράφεις πάνω πάνω ότι το Qos πιάνει μόνο στο uplink; Και λέω γιατί γ@!#@ι το σύμπαν. Ότι ρύθμιση βάζω πιάνει και στο downlink και στο uplink και κατάφερα να το κάνω να έχω 2 από 30 Mbps...

Ανάλογα πως το εννοείς. Αν περιορίσεις το uplink σε σημείο που δεν χωράνε ούτε τα ACK packets ναι, είναι εύκολο να έχεις 2 από 30Mbps και ψίχουλα upload.

Ενδεικτικά, ορίζοντας 256000 bps rate σε συσκευή μου, κατάφερα να throttλάρω λόγω upload saturation το download στα 7-8 Mbps. Το upload peakαρε στα 256Kbps.

Αυτό δεν είναι QoS ούτε downstream bandwidth control

[Da1Li5oS]

Αδερφέ εγώ που το θέλω για Ace stream και γενικά να βλέπω ταινίες online κυρίως μέσω torrent, να ακολουθήσω τον οδηγό ή είμαι για αλλού;

[timos71]

Αδερφέ εγώ που το θέλω για Ace stream και γενικά να βλέπω ταινίες online κυρίως μέσω torrent, να ακολουθήσω τον οδηγό ή είμαι για αλλού;

Διαβάσε τον οδηγό και φρόντισε να καταλάβεις τη λογική. Μετά από αυτό εφάρμοσε το στον εξοπλισμό σου σύμφωνα με τις δικές σου ανάγκες. Αν π.χ θες να έχει υψηλότερη προτεραιότητα το ace-stream βρες ποια πόρτα χρησιμοποιεί και βαλτην στο traffic class 1.

[Da1Li5oS]

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


https://drive.google.com/folderview?...7wO-0LzI9Il4l6

[timos71]

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


https://drive.google.com/folderview?...7wO-0LzI9Il4l6

Συμφωνα με τα screenshots που ανεβασες οι ρυθμισεις που εχει φαινονται ακριβως ιδιες με του speedport entry 2i. Οποτε σου προτεινω να ξεκινησεις να διαβαζεις τον οδηγο απο την αρχη και να μας πεις που εχεις προβλημα ή τι σε μπερδευει.

[ghk84]

θελω να δώσω προτεραιότητα στην 192,168,1,248
ειναι σωστές οι ρυθμίσεις?

ολα τα αλλα ειναι default ..

[ghk84]

?????? Ουδείς ?