Mikrotik QoS για IPv4/IPv6

[teodor_ch]

Όταν έχεις γραμμή 29/2.5 για ένα σπίτι
και καθόλου QOS να έχεις μικρό το κακό!

Εμείς που έχουμε 4/1 και αυτό με θεματάκια, το QOS επιβάλλεται και μάλιστα να φέρνει τη γραμμή στα όρια της.

Στο πρακτικό κομμάτι.

Το QOS σου, έτσι όπως το έχεις στήσει, πιο πολύ κόβει παρά δίνει προτεραιότητες.
Αν βάλεις τα max-limit σχετικά ψηλά 20/2 για πχ. τις ουρές QOS3 και QOS8,
με την QOS8 να τερματίζει τη γραμμή,
αν ξεκινήσεις ένα μεγάλο FTP Download θα δώσει τα 20mbit στην QOS3 και θα μηδενίσει σχεδόν την QOS8?
Γιατί εγώ δε το βλέπω αυτό.

Και το άλλο θέμα.
Αν μέσα απο τους torrent clients δεν βάλεις όρια
δεν βλέπεις dropped πακέτα στο MK με max-limit=14/2 που έχεις?
Χωρίς το τρικ με το τεράστιο buffer που έκανα, πώς κόβει την ταχύτητα χωρίς να ρίχνει πακέτα?

- - - Updated - - -

Επίσης, έχεις τα torrents με pcq- default κανόνες οι οποίοι είναι FIFO ουρές χωρισμένες ανα classifier.

Στον pcq-download-default classifier είναι ο dest address.
Δηλαδή αν ο 192.168.1.2 τρέχει Deluge θα έχει ΕΝΑ pcq άρα ΜΙΑ FIFO ουρά.
Καμία διαφορά με εμένα που έχω βάλει FIFO κατευθείαν!

Οπότε το pcq για torrents που λές είναι γενικός κανόνας όταν στο δίκτυο υπάρχουν >1 υπολογιστές που κατεβάζουν torrents.

Σωστά ή μου διαφεύγει κάτι?

- - - Updated - - -

Θα μπορούσε να έχει νόημα στα p2p pcq-download με classifier=src-address ώστε να τρέχουν παράλληλα τα chunks αλλά θέλει σκέψη και έρευνα και δεν έχω χρόνο και όρεξη!

[deniSun]

1. Το μεγάλο bw δεν σε απαλλάσσει από την χρήση του QoS.
Το QoS το βάζεις για να έχεις δικαιοσύνη στην χρήση του bw.
Δηλαδή όταν ο Χ-χρήστης κατεβάζει ένα αρχείο, ο Υ να έχει την εντύπωση ότι δεν αδικείται και ότι και αυτός με κάποιον τρόπο εξυπηρετείται δίκαια χωρίς καθυστερήσεις.

2. Σε bw <24Μ δυσκολεύουν τα πράγματα.
Με την έννοια ότι θα πρέπει να επωφεληθείς όσο περισσότερο bw γίνεται.
Φυσικά δεν θα έχεις την πολυτέλεια όπως εγώ να χαρίζω 10-15Μ αλλά το να αφήνεις 1Μ αέρα για το browsing σε βάρος του dw δεν νομίζω θα σε στερήσει πολλά πράγματα.
Κάθε άλλο θα δίνει την εντύπωση στους χρήστες που σερφάρουν ότι δεν μπουκώνει η γραμμή.
Φυσικά όπως είπα αυτό είναι υποκειμενικό.
Ανάλογα με το τι επιδιώκει ο κάθε ένας.

3. Όπως είπα... το QoS το στήνεις ανάλογα με την χρήση.
Η δική μου η χρήση σε πολλές χρονικές στιγμές είναι:
Ταυτόχρονο torrent, dw large και serfing (+voip).
Δεν με πειράζει αν καθυστερήσουν τα torrent και τα dw.
Με ενδιαφέρει να έχω αποδεκτή ταχύτητα στο dw των αρχείων και των torrent και ταυτόχρονα οι χρήστες να serfάρουν χωρίς να καταλαβαίνουν την διαφορά.
Άρα δεν με ενδιαφέρει να τους στείλω όλους μαζί και να μάχονται ποιος θα πρωτοπάρει το bw αλλά να μπορούν όλοι να είναι ικανοποιημένοι.
Το να κατέβουν τα αρχεία 10 λεπτά αργότερα δεν με ενοχλεί.
Αν όλα δουλέψουν ταυτόχρονα θα δεις ότι το bw δεν φτάνει (άθροισε τα Limits).
Επίσης στα torrents όπως και στα dw έχω πολλαπλά connections.
Άρα αυτό που φαινομενικά φαίνεται ως μία σύνδεση είναι 100άδες.
Εκεί παίζει ρόλο το QoS ώστε να δώσει τις προτεραιότητες που πρέπει.

4. Το είχα αναφέρει και αυτό το θέμα του μηδενισμού.
Τα torrents είναι πολύ επιθετικά.
Αν έχεις ρυθμίσει τον client ώστε να έχει πολλά παράλληλα connections τότε απλά θα δεις τα dw να μηδενίζουν σε ταχύτητα.
Εκεί βοηθάει το burst των ουρών.
Αλλά και πάλι δεν θα δεις θαύματα αν δεν αφήσεις αέρα στην γραμμή σου.
Πολύ απλά... από την μια θα έχεις ένα connections ή το πολύ 4 για ένα dw αρχείο και από την άλλη 100άδες για ένα torrent.
Φαντάσου τι γίνεται από θέμα connections όταν βάλεις και δεύτερο torrent.
Πρακτικά... το καλύτερο QoS να έχεις στήσει αν μπουκώνεις έτσι το ρούτερ, δεν πρόκειται να δεις τίποτε άλλο να κινείται πλην των torrent.
Αν όμως αυτό σε βολεύει, δηλαδή το κύριο μέλημά σου είναι να κατεβάζεις όσο γίνεται ταχύτερα αρχεία τότε το αφήνεις ως έχει.
Σε εμένα και στο νέο αλλά και στο αμέσως προηγούμενο configuration ποτέ δεν μηδενίζει η ταχύτητα ούτε στο dw αλλά ούτε και στα torrent (μιλάμε πάντα για παράλληλη χρήση αυτών).

5. Τον torrent client θα πρέπει να τον ρυθμίσεις.
Είτε τον αφήνεις στις ρυθμίσεις που θα σου προτείνει, είτε ακόμα χειρότερα ακολουθήσεις κάποιο tweak από τα άθλια που κυκλοφορούν.
Το μέγεθος του buffer το ορίζεις με βάση τις ρυθμίσεις του κάθε προγράμματος.
πχ διαφορετικό buffer θέλεις για ftp από filezilla και διαφορετικό από firefox.
Δεν υπάρχει κάποιος κανόνας γι αυτό.
Ρυθμίζεις τον buffer με βάση την χρήση που κάνεις, τις ρυθμίσεις των προγραμμάτων και το είδος του προγράμματος.

6. Για να ρίξεις την ταχύτητα έχεις τους εξής τρόπους:
α. με drop πακέτα (όπως έκανα αρχικά)
β. με ορισμό ανάλογου buffer ώστε να συγκρατεί Χ-πακέτα και να στέλνει Χ-Υ στους χρήστες.
Η τιμή Υ θα πρέπει να είναι τέτοια ώστε να μην προλαβαίνει ο buffer να υπερχειλίσει.
Δηλαδή αν είναι πολύ μικρή θα γεμίζει ο buffer γρηγορότερα απ ότι θα αδειάσει και αντίστροφα.
Είναι το αμέσως προηγούμενο configuration που είχα.
γ. με ορισμό buffer όπως παραπάνω και ανάλογες δηλώσεις στις pcq ουρές για limits (το τελευταίο configuration) όπως επίσης και στις δηλώσεις των ουρών για όρια.
Αυτά τα όρια δεν μπορείς να τα έχεις σε fifo ουρές.

7. Ναι οι pcq ουρές χρησιμοποιούν ουρές fifo.
Αλλά δεν είναι μόνο αυτό.
Υπάρχει ολόκληρος αλγόριθμος από πίσω.
Αν χρησιμοποιείς πρόγραμμα με ένα connections δεν θα δεις διαφορά.
Αλλά πόσα είναι αυτά.
Να σου πω παραδείγματα που επωφελήσε από pcq:
α. firefox με pipeline
β. dw manager με πολλαπλά connections
γ. ftp σε server που επιτρέπει πολλάπλά connections
δ. torrents
κλπ
Για να δεις αυτό που λέω, άνοιξε μια ουρά και δες πόσες pcq ουρές δημιουργούνται.

8. Για τα pcq-download που λες δεν πάει έτσι.
Στο δικό μου configuration χρησιμοποιώ simple ουρές μόνο για το up.
Αν πχ επικοινωνήσει το torrent με τον Χ-χρήστη αυτό θα γίνει με αίτηση (up) που θα κάνει το πρόγραμμα.
Άρα η απάντηση θα έρθει υποχρεωτικά από την ίδια ουρά που στάλθηκε και η αίτηση.
Άρα στην ουσία θα δουλέψει θα δημιουργηθούν τόσες ουρές στο dw για τον Χ-χρήστη όσες και οι αιτήσεις up.
Αν θέλεις δοκίμασέ το να δεις ότι δουλεύει όπως σου το λέω.
Το έχω ελεγμένο.
Γι αυτό και δεν χρησιμοποιώ trees γιατί δεν με ενδιαφέρει να έχω διαφορετικά στοιχεία στο up/dw.

9. Αν δεις δύο configuration πιο πίσω το up/dw classifier το είχα αντίστροφα στις ουρές.
Αυτό μπορείς να το κάνεις όταν θέλεις να πάρει ο Χ-χρήστης συγκεκριμένο bw ανεξάρτητα με το πόσα connections ανοίγει.
Έστω ότι έχεις δύο χρήστες Χ και Υ.
Και ο Χ έχει 100 connections και ο Υ-10.
Αν το bw που έχεις είναι 30Μ τότε:
Αν έχεις τα classifier ανάλογα στα up/dw τότε ο Χ θα πάρει 30*100/110=27Μ και ο Υ επίσης 30*10/100=3Μ.
Στην περίπτωση που δώσεις ανάποδα τα up/dw στον classifier ο Χ θα πάρει 30/2=15Μ όπως και ο Υ.

[teodor_ch]

1. Δεν είπα ότι απαλλάσσει. Αλλά η διαφορά είναι χαοτική στο 4/1-με-QOS με 20/2-χωρίς-QOS.

2,3. Πιστεύω ότι κάτι κάνουμε λάθος ή απλά το MK δεν μπορεί να το κάνει (το θεωρώ απίθανο). Όταν με το USR9105 είχα QOS και κατέβαζα χωρίς όριο με το emule και όταν ζητούσα BW έβλεπα στο emule να πέφτει το download άμεσα. Και μιλάμε για γραμμές 512/128 (κάτι τέτοιο) με Vivodi!
Δεν δέχομαι να πρέπει να χαρίζω BW και το MK να μή μπορεί να κόβει όταν το ζητάει κάποια ουρά με καλύτερη προτεραιότητα.

4. Για τα p2p: είτε 1 σύνδεση είτε 500 όλα περνάνε απο την ίδια ουρά. Το θέμα είναι οτι απο τη στιγμή που φεύγουν οι αιτήσεις (ACK?) απο μένα για τα 500 παράλληλα πακέτα, δεν θα μπορώ να τα καθυστερήσω μέχρι να έχουν ήδη φτάσει (και να μου μπουκώσουν το download)?
Άρα μήπως η λύση είναι να συνδέσω το upload των αιτήσεων (ACK?) για κατέβασμα με το download?

7,8,9.

Απο το δικό σου conf

add comment="______QoS_8 Torrents except VoIP-SW" name=QoS_8 packet-marks=\
		QoS_8 parent=All_others queue=pcq-upload-default/pcq-download-default \
		target=pppoe-out1

Εκτός και αν έχεις αλλάξει τα default pcq types,
έχεις στο upload classifier=src-address = τη δικιά σου = ΜΙΑ
και στο download classifier=dst-address = τη δικιά σου = ΜΙΑ

Εγώ έχω queue tree με

add name="P2P Download" packet-mark=P2P-in parent="Priority 8 download" queue=big-downloads
add max-limit=500k name="P2P Upload" packet-mark=P2P-out parent="Priority 8 Upload"

με firewall mangle

add action=mark-connection chain=prerouting comment="P2P udp for reference" new-connection-mark=P2P port=59600-59799 protocol=udp
add action=mark-connection chain=prerouting comment="P2P tcp for reference" new-connection-mark=P2P port=59600-59799 protocol=tcp
add action=mark-packet chain=prerouting comment="Mark P2P OUT" connection-mark=P2P in-interface=bridge-local new-packet-mark=P2P-out packet-mark=no-mark \
    passthrough=no
add action=mark-packet chain=prerouting comment="Mark P2P IN" connection-mark=P2P in-interface=pppoe-out1 new-packet-mark=P2P-in packet-mark=no-mark \
    passthrough=no

και όταν βάζω στο P2P-in pcq-download-default
και το P2P-out pcq-upload-default
παίρνω ΕΝΑ PCQ για το κάθε ένα!
Ακριβώς όπως τα λέει η θεωρία.

Η διαφορά μας τώρα που ξαναείδα τα mangles σου είναι ότι δε διαχωρίζεις τα QOS8 download απο τα upload αλλά τα μαρκάρεις όλα ως μία ομάδα. Βάλε ότι δεν έχω ιδέα καθόλου απο Queue simple οπότε και αδυνατώ να καταλάβω πώς σου πετυχαίνει.

[deniSun]

1. Δεν είπα ότι απαλλάσσει. Αλλά η διαφορά είναι χαοτική στο 4/1-με-QOS με 20/2-χωρίς-QOS.

2,3. Πιστεύω ότι κάτι κάνουμε λάθος ή απλά το MK δεν μπορεί να το κάνει (το θεωρώ απίθανο). Όταν με το USR9105 είχα QOS και κατέβαζα χωρίς όριο με το emule και όταν ζητούσα BW έβλεπα στο emule να πέφτει το download άμεσα. Και μιλάμε για γραμμές 512/128 (κάτι τέτοιο) με Vivodi!
Δεν δέχομαι να πρέπει να χαρίζω BW και το MK να μή μπορεί να κόβει όταν το ζητάει κάποια ουρά με καλύτερη προτεραιότητα.

4. Για τα p2p: είτε 1 σύνδεση είτε 500 όλα περνάνε απο την ίδια ουρά. Το θέμα είναι οτι απο τη στιγμή που φεύγουν οι αιτήσεις (ACK?) απο μένα για τα 500 παράλληλα πακέτα, δεν θα μπορώ να τα καθυστερήσω μέχρι να έχουν ήδη φτάσει (και να μου μπουκώσουν το download)?
Άρα μήπως η λύση είναι να συνδέσω το upload των αιτήσεων (ACK?) για κατέβασμα με το download?

7,8,9.

Απο το δικό σου conf

add comment="______QoS_8 Torrents except VoIP-SW" name=QoS_8 packet-marks=\
		QoS_8 parent=All_others queue=pcq-upload-default/pcq-download-default \
		target=pppoe-out1

Εκτός και αν έχεις αλλάξει τα default pcq types,
έχεις στο upload classifier=src-address = τη δικιά σου = ΜΙΑ
και στο download classifier=dst-address = τη δικιά σου = ΜΙΑ

Εγώ έχω queue tree με

add name="P2P Download" packet-mark=P2P-in parent="Priority 8 download" queue=big-downloads
add max-limit=500k name="P2P Upload" packet-mark=P2P-out parent="Priority 8 Upload"

με firewall mangle

add action=mark-connection chain=prerouting comment="P2P udp for reference" new-connection-mark=P2P port=59600-59799 protocol=udp
add action=mark-connection chain=prerouting comment="P2P tcp for reference" new-connection-mark=P2P port=59600-59799 protocol=tcp
add action=mark-packet chain=prerouting comment="Mark P2P OUT" connection-mark=P2P in-interface=bridge-local new-packet-mark=P2P-out packet-mark=no-mark \
    passthrough=no
add action=mark-packet chain=prerouting comment="Mark P2P IN" connection-mark=P2P in-interface=pppoe-out1 new-packet-mark=P2P-in packet-mark=no-mark \
    passthrough=no

και όταν βάζω στο P2P-in pcq-download-default
και το P2P-out pcq-upload-default
παίρνω ΕΝΑ PCQ για το κάθε ένα!
Ακριβώς όπως τα λέει η θεωρία.

Η διαφορά μας τώρα που ξαναείδα τα mangles σου είναι ότι δε διαχωρίζεις τα QOS8 download απο τα upload αλλά τα μαρκάρεις όλα ως μία ομάδα. Βάλε ότι δεν έχω ιδέα καθόλου απο Queue simple οπότε και αδυνατώ να καταλάβω πώς σου πετυχαίνει.

1. Εξυπακούεται αυτό που λες.

2.3. Ποιος σου είπε ότι δεν ρίχνει την ταχύτητα;
Μια χαρά την ρίχνει.
Όταν δεν έχεις ορίσει όρια ή το bw δεν επαρκεί, αυτό το πράγμα κάνει.
Ρίχνει την ταχύτητα στις χαμηλότερες ουρές.
Αλλά άλλο πράγμα να σου ρίξει την ταχύτητα σε γραμμή 512 που λες (πόσες παράλληλες συνδέσεις να είχες και άλλο σε γραμμή 4Μ και άλλο σε γραμμή 24 και άλλο σε γραμμή 30/50.
Όσο μεγαλώνει το bw και αυξάνεται ο αριθμός των συνδέσεων θα έχεις λιγότερη απόκριση στην μεταβολή της ταχύτητας.
Τα όρια και το burst τα χρησιμοποιείς γι αυτόν τον λόγο.

4. Αν πας να βάλεις τα ack σε άλλη ουρά θα πρέπει να τα πιάνεις σε επίπεδο πακέτων και όχι connection.
Γιατί με την δεύτερη περίπτωση όλες οι συνδέσεις σου θα εμπίπτουν στην συγκεκριμένη ουρά των ack.
Και επίσης στην περίπτωση των connection θα πρέπει να εξαιρείς την περίπτωση των ack.

7.8.9. Όπως είπα στα αρχικά configuration είχα ανάποδα τα up/dw.
Το dw στο ΜΤ αντιστοιχεί στο up του ΗΥ.
Άρα όταν στο dw του ΜΤ είναι ορισμένη dst-address και έχεις 100 χρήστες διαφορετικούς στο torrent... πώς είναι δυνατόν να σου βγάζει μόνο μία σύνδεση;
Σε εμένα με pcq αναγράφεται κανονικότατα ο αριθμός των υπό-ουρών που δημιουργούνται για κάθε ουρά.

Για το πως δουλεύουν... το εξήγησα με παράδειγμα.

[macro]

δε τα ριχνει deni. Εγω εχω δοκιμασει στο QoS8 burst=12 και limit=10 με αναλογες τις υπολοιπες τιμες και κατεβαζε με 18 το τορρεντ.

[teodor_ch]

7,8,9.
Για το ανάποδο του up/down,
με μπέρδεψες γιατί όντως το έχεις ανάποδα!
Και πιο πρίν αντίστροφα στο ήδη ανάποδο!!!

Στο wiki
http://wiki.mikrotik.com/wiki/Manual:Queue
To upload είναι το upload και το download το download!!!

Note: Since RouterOS v6 these settings are combined in the option target where you can specify either of the above. Target is to be viewed from perspective of the target. If you want to limit your users's upload capability, set "target upload".

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

2.3
Πάντως το burst το έχω για fine tuning και όχι για το βασικό παράγοντα.
Ειδικά στα p2p δεν με ενδιαφέρει καθόλου το burst.
Με το να διαχωρίζουμε και σε http low και heavy ούτε και εκεί έχει σημαντική χρήση.

4. Όλα τα mangle τα έχω σε επίπεδο πακέτων και χωρισμένα σε upload/download

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

[deniSun]

δε τα ριχνει deni. Εγω εχω δοκιμασει στο QoS8 burst=12 και limit=10 με αναλογες τις υπολοιπες τιμες και κατεβαζε με 18 το τορρεντ.

Μην μπερδεύετε το burst με τα Limit.
Έχω πει συγκεκριμένα πώς να έχεις burst και limit είτε σε επίπεδο ουράς (προηγούμενο configuration) είτε σε επίπεδο ουράς και ρυθμίσεων ουρών (τελευταίο configuration).

7,8,9.
Για το ανάποδο του up/down,
με μπέρδεψες γιατί όντως το έχεις ανάποδα!
Και πιο πρίν αντίστροφα στο ήδη ανάποδο!!!

Στο wiki
http://wiki.mikrotik.com/wiki/Manual:Queue
To upload είναι το upload και το download το download!!!


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

2.3
Πάντως το burst το έχω για fine tuning και όχι για το βασικό παράγοντα.
Ειδικά στα p2p δεν με ενδιαφέρει καθόλου το burst.
Με το να διαχωρίζουμε και σε http low και heavy ούτε και εκεί έχει σημαντική χρήση.

4. Όλα τα mangle τα έχω σε επίπεδο πακέτων και χωρισμένα σε upload/download

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

7.8.9. Μιλάω πάντα για πράγματα που έχουν δοκιμαστεί στην πράξη.
Όταν μιλάμε για ρυθμίσεις ρούτερ σημαίνει ότι είμαστε "πάνω" στον ρούτερ.
Αν εσύ ήσουν ο ρούτερ τι θα θεωρούσες up και τι dw.
Προφανώς το up θα ήταν αυτό που στέλνεις στους client.
Άρα το dw που λέμε εμείς.
Και το αντίστροφο.
Μια δοκιμή και θα σε πείσει.
Φτιάξε μια απλή ουρά και ρίξε όλη την κίνηση επάνω της.
Δες τι μετράει το up και τι το dw.
Απλά πράγματα...

2.3. Στο http low δεν έχει νόημα το burst γιατί η κίνηση είναι πολύ μικρή και δεν θα το χρειαστεί.
Στο http heavy και torrent όμως έχει μεγάλη σημασία.
Με απλά λόγια...
Αν δεν το έχεις, και έχεις ταυτόχρονα torrent και dw, τότε θα δεις ότι ένα από τα δύο θα αρχίσει να μειώνει την ταχύτητα με κίνδυνο ακόμα και να την μηδενίσει, ανάλογα με το πόσο επιθετικό είναι το άλλο.
Το burst, μέσα σε όλα τα άλλα, σου εγγυάται ότι κάτι τέτοιο δεν θα το αφήσει να συμβεί.

4. Γιατί πακέτα και όχι connections;

[teodor_ch]

7.8.9. Μιλάω πάντα για πράγματα που έχουν δοκιμαστεί στην πράξη.
Όταν μιλάμε για ρυθμίσεις ρούτερ σημαίνει ότι είμαστε "πάνω" στον ρούτερ.
Αν εσύ ήσουν ο ρούτερ τι θα θεωρούσες up και τι dw.
Προφανώς το up θα ήταν αυτό που στέλνεις στους client.
Άρα το dw που λέμε εμείς.
Και το αντίστροφο.
Μια δοκιμή και θα σε πείσει.
Φτιάξε μια απλή ουρά και ρίξε όλη την κίνηση επάνω της.
Δες τι μετράει το up και τι το dw.
Απλά πράγματα...

Καταρχάς το ρούτερ είναι στη μέση.
Οπότε είναι ανάλογα πώς το κοιτάς.
Προς το WAN ή προς το LAN?

Ανεξάρτητα απο το πώς θέλεις να το κοιτάξεις,
όταν λέμε upload το σωστό είναι να εννοούμε upload (είτε του WAN είτε των clients).
Έτσι το έχει και το WIKI!!!!!
Και ναί, έφτιαξα queue simple ουρά και βλέπω 4M στο download και 900k στο upload!

/queue simple
add max-limit=900k/4M name="Total Traffic" priority=1/1 queue=default/default target=bridge-local total-queue=default

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

2.3
Το burst στα http heavy αν και τα έχω ξαναπεί,
με βάση το δικό σου config

add action=mark-packet chain=forward comment="______________HTTP-S Large" \
		connection-bytes=500000-0 connection-mark=QoS_HTTP new-packet-mark=QoS_3 \
		passthrough=no protocol=tcp

Έχει τα πρώτα 0.5MB με HTTP-Small και άρα QOS2 με ήδη αυξημένα όρια και ήδη άλλο ένα burst.
Μετά γίνονται HTTP-S Large και περιορίζονται. Ανάλογα τις προτιμήσεις βάζεις και burst ή όχι αλλά πρέπει να γνωρίζεις ότι ήδη έχουν περάσει ένα burst. Εγώ προτίμησα επειδή θεωρώ το burst απρόβλεπτο, να φτιάξω μία ενδιάμεση ουρά HTTP-Medium.

Στο p2p το οποίο το μόνο που θέλω να κάνω είναι να το περιορίσω έχει κάποιο λόγο να του βάλω burst?


Έπειτα, επειδή έχω κολλήσει λίγο με το pcq για τα torrents και κάνω τις δοκιμές μου για να βγάλω άκρη.
Είπες (αν κατάλαβα/θυμάμαι καλά) να βάζουμε το όριο μέσα στο queue kind του pcq (ΚΑΙ στην ουρά βέβαια).
Αυτό το όριο είναι για τη μέγιστη ταχύτητα ανα pcq-ουρά. Ποιό το νόημα όταν έχουμε >>100 συνδέσεις με max-limit 4M να του πώ 1Μ pcq rate?
Άσε που ακόμα δεν έχω χωνέψει γιατί ντε και καλά πρέπει να χωρίσουμε αυτές τις >>100 συνδέσεις σε pcq-ουρές αλλά το δέχομαι με τη λογική να buffάρει ( ) ανα connection και να μή ρίχνει τυχαία πακέτα καθιστώντας άχρηστο το download.
Και απο ότι είδα (τώρα το κατάλαβα με όλες τις αναποδιές!) συμφωνούμε στο μεγάλο buffer

Στο δικό μου configuration μια καλή λύση είναι να οριστούν όρια για τις ουρές pcq-up με:

limit: 10M
total-limit: 16M

και pcq-dw με:

limit: 1M
total-limit: 2.5M

Με τις παραπάνω τιμές έχω 0-drop σε όλα (χρησιμοποιώ τις ίδιες ρυθμίσεις για όλες τις ουρές).

[deniSun]

1. Τι άλλο να κάνω για να σε πείσω...
Αρχικά αυτό που λες για το ρούτερ είναι αυτό που σου είπα.
Και σου το λέω ξανά.
Είσαι το ρούτερ... και θέλεις να στείλεις δεδομένα στην ether2 τι κάνεις;
up ή dw;
Αυτό που σου είπα με το να κάνεις μια απλή ουρά και να δοκιμάσεις το έκανες;

2. 3. Αυτό που περιγράφεις για το ότι πέρασαν ένα burst... τι πρόβλημα υπάρχει;
Σε καθυστερεί σε τίποτε;
Σου εξήγησα για το πόσο απαραίτητο είναι το burst κυρίως στα dw και p2p.

Το max limit αναφέρεται σε όλη την Χ-ουρά.
Το pcq-rate αναφέρεται στην μέγιστη ταχύτητα που μπορεί να διαθέσει για κάθε υπό-ουρά.

[teodor_ch]

Για το 1 μόνο προς το παρόν,
έβαλα μία simple ουρά με τον κώδικα που δίνω στο προηγούμενο ποστ μου και δουλεύει σωστά το up/down.
Όπως τα λέει και το wiki! Το τονίζω γιατί δεν διαφωνείς μόνο μαζί μου αλλά και με το επίσημο wiki!

Το αποτέλεσμα είναι το ίδιο εφόσον παντού τα βάζεις ανάποδα.

Αλλά το λέει όσο πιο ξεκάθαρα γίνεται!

Flow Identifiers
target (multiple choice: IP address/netmask) : list of IP address ranges that will be limited by this queue.

http://wiki.mikrotik.com/wiki/Manual...#Simple_Queues

E...

target=pppoe-out1

άρα

pppoe-out1 will be limited by this queue.

Ενώ πρέπει να στοχεύεις το εσωτερικό σου δίκτυο.
Πάλι θα δουλέψει αλλά τα βάζεις όλα ανάποδα!

Κάνουμε παρόμοια συζήτηση με τότε που σου αντέγραφα πάλι απο το wiki ότι χωρίς το drop all others του λές allow all others

[deniSun]

Σημασία δεν έχει το target αλλά το που πιάνεις τα mangle.
Εγώ πιάνω το up στα mangle και προφανώς αυτό σε μπέρδεψε.
Στο wiki κλπ μιλάνε για mangle και στο up και στο dw.
Δεν είναι θέμα ορθά ή ανάποδα.
Είναι από που το βλέπεις.
Όσο για το wiki κλπ... τα περισσότερα αναφέρονται για QoS και στο up και στο dw.
Εγώ κάνω QoS μόνο στο up.
Το dw δεν το περνάω από QoS.

[teodor_ch]

Τώρα είναι που δε σε καταλαβαίνω καθόλου.
Τι εννοείς ότι δεν περνάς το dw (που λογικά εννοείς download (το 22 απο τα 22/2 της σύνδεσης!!!)) απο QOS?

Αφού έχεις βάλει όρια και έχω ανοίξει τη συζήτηση για να κόψω τα p2p downloads!!!
Τί συζητάμε τόση ώρα!

[deniSun]

Τώρα είναι που δε σε καταλαβαίνω καθόλου.
Τι εννοείς ότι δεν περνάς το dw (που λογικά εννοείς download (το 22 απο τα 22/2 της σύνδεσης!!!)) απο QOS?

Αφού έχεις βάλει όρια και έχω ανοίξει τη συζήτηση για να κόψω τα p2p downloads!!!
Τί συζητάμε τόση ώρα!

Το QoS το κάνεις για να διασφαλίσεις την ποιότητα της σύνδεσής σου.
Το πρόβλημα βρίσκεται στα σημεία που έχεις bottleneck.
Το μόνο σημείο που έχεις bottleneck είναι στο up των δεδομένων.
πχ έχεις 100/1000Μ από πλευράς ether και στην dsl 1/2.5/5Μ.
Άρα εκεί το χρειάζεσαι ώστε να βάλεις σε μια τάξη τα δεδομένα σου.
Δηλαδή να του πεις ότι αν στον ρούτερ φτάσουν ταυτόχρονα αιτήσεις για έξοδο για http, dw, torrent, να τα βάλει σε μια σειρά ώστε να φύγουν πρώτα τα http, μετά τα dw κοκ.
Έτσι διασφαλίζεις ότι με κάποιον τρόπο, αφού τα http έφυγαν πιο νωρίς θα σου έρθουν και πίσω τα δεδομένα πιο γρήγορα.

Στο dw δεν χρειάζεσαι QoS γιατί αρχικά δεν έχεις bottleneck.
Από την μια έχεις την γραμμή dsl με 24/30/50Μ και από την άλλη την ether με 100/1000Μ.
Άρα αν σου έρθουν στο ρούτερ πρώτα τα dw και μετά τα http γιατί εσύ να τα καθυστερήσεις βάζοντάς τα σε άλλη σειρά πχ πρώτα τα http και μετά τα dw;
Αφού το bw της ether είναι υπέρ αρκετό για να τα εξυπηρετήσει.
Άρα εδώ δεν χρειάζεσαι το QoS.

[macro]

Επανερχομαι με τροφη για σκεψη.........

Deni θα ηθελα να σου πω οτι η τιμη ack packet size=0-123 ειναι λαθος μιας και στο tcp δεν υπαρχει μικροτερη τιμη byte κατω απο 40, αρα το σωστο ειναι = 40-123

Πανω σε αυτο δοκιμαζω ack packet size=490-809 QoS8 και βλεπω οτι υπαρχει δραστηριοτητα, δλδ πεφτει το τορρεντ οταν σερφαρω ας πουμε.

Αυτο το κανω και στο udp σε ολες τις πορτες ομως, δλδ δε δηλωνω τπτ στις πορτες.


Δεν εχω καταληξει καπου ακομη απλα οπως σας ειπα........ τροφη για σκεψη και δοκιμες.

[deniSun]

Επανερχομαι με τροφη για σκεψη.........

Deni θα ηθελα να σου πω οτι η τιμη ack packet size=0-123 ειναι λαθος μιας και στο tcp δεν υπαρχει μικροτερη τιμη byte κατω απο 40, αρα το σωστο ειναι = 40-123

Πανω σε αυτο δοκιμαζω ack packet size=490-809 QoS8 και βλεπω οτι υπαρχει δραστηριοτητα, δλδ πεφτει το τορρεντ οταν σερφαρω ας πουμε.

Αυτο το κανω και στο udp σε ολες τις πορτες ομως, δλδ δε δηλωνω τπτ στις πορτες.


Δεν εχω καταληξει καπου ακομη απλα οπως σας ειπα........ τροφη για σκεψη και δοκιμες.

Δεν είναι λάθος απλά εσύ το συγκεκριμενοποιείς.
Είτε το δηλώσω 0-123 είτε 40-123 θα το πιάσουμε και οι δύο κανονικά.

Με ack packet size=490-809 τι ελέγχεις και γιατί;