Mikrotik QoS για IPv4/IPv6

[macro]

Πιθανον να ειναι και bug. Εγω δε το παρατηρω αυτο σε qos up-down/pre-post packet mark, simple. Εχω ακριβως την ιδια συμπεριφορα ειτε κλειστα ειτε ανοιχτα mangles. Πρεπει να κανεις και αλλες δοκιμες, δλδ παιξε με απευθειας dns και οχι cache καθως και δες τα και με default queue type. Αν μου ερθει και κατι αλλο στο μυαλο θα το γραψω. Αν δε βρεις ακρη επειδη ειναι ενδιαφερον αυτο που γραφεις κανε μια ερωτηση στο ΜΤ forum και πες μας τι σου ειπαν.

[deniSun]

Πιθανον να ειναι και bug. Εγω δε το παρατηρω αυτο σε qos up-down/pre-post packet mark, simple. Εχω ακριβως την ιδια συμπεριφορα ειτε κλειστα ειτε ανοιχτα mangles. Πρεπει να κανεις και αλλες δοκιμες, δλδ παιξε με απευθειας dns και οχι cache καθως και δες τα και με default queue type. Αν μου ερθει και κατι αλλο στο μυαλο θα το γραψω. Αν δε βρεις ακρη επειδη ειναι ενδιαφερον αυτο που γραφεις κανε μια ερωτηση στο ΜΤ forum και πες μας τι σου ειπαν.

Για την cache είπα ότι την καθαρίζω.
Είτε είναι του browser είτε του dns.

Παρατήρησα ότι έχει να κάνει με τα trees.
Για να είμαι πιο συγκεκριμένος:

add action=mark-connection chain=postrouting comment="QoS_4_5 Small-Large HTTP\
    -S, FTP, SSH, Telnet, SMTP, POP3-S, IMAP-S, SMTP-S" connection-mark=\
    no-mark new-connection-mark=QoS_4_5-UP out-interface=all-ppp passthrough=\
    yes port=20,21,22,23,25,80,110,143,443,465,587,993,995,8080 protocol=tcp
add action=mark-packet chain=postrouting connection-bytes=0-5000000 \
    connection-mark=QoS_4_5-UP new-packet-mark=QoS_4-UP passthrough=no
add action=mark-packet chain=postrouting connection-bytes=5000000-0 \
    connection-mark=QoS_4_5-UP new-packet-mark=QoS_5-UP passthrough=no

Αυτό από μόνου του (με change mss) και με ένα απλό tree με pcq και parent στα 4-5 το global
έχει την προβληματική συμπεριφορά με τους μεγάλους χρόνους που ανέφερα.

Αν κάνω disable το tree... όλα οκ.
Αν προσθέσω (στην αρχή ή στο τέλος δεν έχει σημασία):

add action=mark-connection chain=prerouting comment="QoS_DW All Download" \
    in-interface=all-ppp new-connection-mark=QoS-DW passthrough=yes
add action=mark-packet chain=prerouting connection-mark=QoS-DW \
    new-packet-mark=QoS-DW passthrough=no

τότε όλα οκ...
Παίζει ακόμα και χωρίς το packet mark του dw.
Παίζει ακόμα και αν κάνω disable το αντίστοιχο QoS στο tree.
Παίζει ακόμα και αν κάνω νέο μαρκάρισμα κάτι που δεν υπάρχει στο tree.

Αρχικά πίστεψα ότι πρέπει ΥΠΟΧΡΕΩΤΙΚΑ να κάνω mangle όλο το traffic.
Αυτό που προτείνουν όλα τα manual.

Τελικά δοκιμάζοντας μια νέα υλοποίηση παίζει πολύ καλά, ίσως καλύτερα από τα προηγούμενα.
Στην υλοποίηση αυτή έχω τα παρακάτω:
1. Στο tree μόνο UP
2. Στα mangles:
α. Ξεκινάω με mss και ότι έχει να κάνει ΜΟΝΟ με packet marks χωρίς connections.
β. Κάνω δύο jump ένα για μαρκαρισμένες συνδέσεις και ένα για μη, αντίστοιχα σε chains για μαρκάρισμα σύνδεσης και πακέτων, δηλώνοντας μόνο out-interface.
γ. Στο μαρκάρισμα συνδέσεων έχω όλες τις ανάλογες δηλώσεις χωρίς passthrough και out-interface.
δ. Ακολουθούν τα μαρκαρίσματα πακέτων που αφορούν τα αντίστοιχα connections, επίσης χωρίς passthrough και out-interface.

Έχει το λιγότερο cpu load απ όσα έχω δοκιμάσει έως τώρα.
Δείχνει να μαρκάρει τα πάντα σωστά.
Δείχνει να αποδίδει πολύ καλύτερα από τα υπόλοιπα.

ΥΓ
Γράφω "δείχνει" γιατί ελέγχω μόνο το up, οπότε θέλει πολύ προσοχή ώστε να μην πιάνεις παραπανίσια κίνηση από το dw.

[deniSun]

Από το προηγούμενο post αφαιρώ ότι έχει να κάνει με ack.

[teodor_ch]

Από το προηγούμενο post αφαιρώ ότι έχει να κάνει με ack.

Θα συμφωνήσω.
Έτσι το είχα απο το 2017
ίδια φιλοσοφία με queue trees

[deniSun]

Θα συμφωνήσω.
Έτσι το είχα απο το 2017
ίδια φιλοσοφία με queue trees

Το έχω διαμορφώσει σύμφωνα με τα επόμενα post από #1304.

[macro]

Αν εννοειτε οτι εχετε αφαιρεσει τα acks......... το ιδιο και εγω μιας και ειναι λιγο γενικος κανονας.

Κατι αλλο που θελω να μου απαντησετε..... εχω κανει load balance 2 γραμμες και απο τη δευτερη που εφαρμοζω κυριως το browsing εφαρμοζω QOS. Σε τορρεντς και σε φουλ τερματισμενο κατεβασμα πανω απο 3ΜΒ βλεπω cpu 40-60% περιπου.

Εσεις?

[deniSun]

Αν εννοειτε οτι εχετε αφαιρεσει τα acks......... το ιδιο και εγω μιας και ειναι λιγο γενικος κανονας.

Κατι αλλο που θελω να μου απαντησετε..... εχω κανει load balance 2 γραμμες και απο τη δευτερη που εφαρμοζω κυριως το browsing εφαρμοζω QOS. Σε τορρεντς και σε φουλ τερματισμενο κατεβασμα πανω απο 3ΜΒ βλεπω cpu 40-60% περιπου.

Εσεις?

Ναι τα έχω αφαιρέσει.

[macro]

Deni αν μπορεις ποσταρε το queue tree που εχεις για να το διαμορφωσω στη δικια μου γραμμη.

[macro]

Η αληθεια ειναι οτι δεν ειδα και πολλες διαφορες αναμεσα σε simple και tree. Βασικα στο tree για καποιο λογο, δε σου δειχνει τα drop packets και ετσι δε μπορεις να κανεις fine tuning. Απο την αλλη ομως, λογω global, επειδη εχω 2 wan αρκει να βαλεις τους μισους κανονες.

Κατι αλλο που τελικα ειδα ειναι οτι η parent γενικως δε χρειαζεται να υπαρχει και στα 2. Το QOS δουλευει ακριβως το ιδιο, εχεις δεν εχεις parent. Aπο οσο καταλαβαινω parent θα χρειαστει καποιος, μονο αν θελει να κανει "κολπα"........... δλδ απο 2 και πανω ή καμια.

[deniSun]

Η αληθεια ειναι οτι δεν ειδα και πολλες διαφορες αναμεσα σε simple και tree. Βασικα στο tree για καποιο λογο, δε σου δειχνει τα drop packets και ετσι δε μπορεις να κανεις fine tuning. Απο την αλλη ομως, λογω global, επειδη εχω 2 wan αρκει να βαλεις τους μισους κανονες.

Κατι αλλο που τελικα ειδα ειναι οτι η parent γενικως δε χρειαζεται να υπαρχει και στα 2. Το QOS δουλευει ακριβως το ιδιο, εχεις δεν εχεις parent. Aπο οσο καταλαβαινω parent θα χρειαστει καποιος, μονο αν θελει να κανει "κολπα"........... δλδ απο 2 και πανω ή καμια.

[macro]

Εχεις καποιο λογο που χρησιμοποιεις bfifo αντι pfifo? Και με πιο τροπο υπολογισες το bandwidth του bfifo? Εμπειρικα? Ελεχγοντας απλα τη κινηση που σε ενδιαφερει σε καθε queue?

Ακομη μια ερωτηση που εχω ειναι εκει που χρησιμοποιεις pcq, για βαζεις και limit? Δεν εχεις δηλωσει limit στο ιδιο το pcq?

[deniSun]

Εχεις καποιο λογο που χρησιμοποιεις bfifo αντι pfifo? Και με πιο τροπο υπολογισες το bandwidth του bfifo? Εμπειρικα? Ελεχγοντας απλα τη κινηση που σε ενδιαφερει σε καθε queue?

Ακομη μια ερωτηση που εχω ειναι εκει που χρησιμοποιεις pcq, για βαζεις και limit? Δεν εχεις δηλωσει limit στο ιδιο το pcq?

1. Χρησιμοποίησα bfifo γιατί ήταν ποιο εύκολο να προσδιορίσω το buffer σε bytes αντί για πακέτα.
2. Το μέγεθος του buffer στις ουρές το καθορίζω με βάση τα drops.
Αρχικά έχω μια λίστα από διευθύνσεις στον ff ~20 διαφόρου περιεχομένου.
Τις ανοίγω όλες ταυτόχρονα ώστε να ελέγξω τι γίνεται σε έναν τέτοιο φόρτο.
Εννοείται ότι έχω πάρει όλα τα σχετικά μέτρα για clear cache, dns (στον ff, HY και τον τοπικό dns server).
Επίσης έχω σκοτώσει πρωτίστως όλα connections.
3. Βασικό κανόνα που ακολουθώ είναι να ορίζω τις ουρές για syn, ack και dns, icmp, ntp requests τόσο ώστε να μην έχω σε καμιά περίπτωση drops.
Τις υπόλοιπες ουρές τις ορίζω με μικρούς buffer.
Στις υπόλοιπες ουρές δεν με ενδιαφέρουν τα drops.
α. γιατί κάνω mangles μόνο στο up, άρα δεν χάνω τίποτε σε μια επανεκμπομπή πακέτου.
β. γιατί με μικρούς buffer έχεις μεν λίγα περισσότερα drops αλλά ταυτόχρονα έχεις πολύ μικρό delay.
To (β) είναι ευεργετικό σε tcp connections όπου ένα delay θα σε καθηλώσει το connections έως το σημείο να σου το μηδενίσει πολλές φορές.
Παρατήρηση: το παραπάνω screenshot είναι παλιό.
Πλέον χρησιμοποιώ σε όλες τις ουρές fifo και καθόλου pcq.
4. Αν και όπως σου είπα δεν χρησιμοποιώ πλέον pcq...
Άλλο το όριο της ουράς και άλλο της pcq.
Το δεύτερο έχει να κάνει με τον buffer.
Το pcq-limit δηλαδή που ορίζεις στο pcq είναι στην ουσία το μέγεθος της ουράς.

[macro]

Ναι καπως ετσι το προσδιοριζω και εγω.

Παντως να ξερεις για το (β) οτι το drops δεν ειναι πανακεια μιας και εκει εχεις delay, επειδη εχεις rerequest. Tο πιο σωστο, τουλαχιστον για μενα ειναι να το φερεις ακριβως εκει που εχεις ελαχιστο drop.

[deniSun]

Ναι καπως ετσι το προσδιοριζω και εγω.

Παντως να ξερεις για το (β) οτι το drops δεν ειναι πανακεια μιας και εκει εχεις delay, επειδη εχεις rerequest. Tο πιο σωστο, τουλαχιστον για μενα ειναι να το φερεις ακριβως εκει που εχεις ελαχιστο drop.

Ναι το ξέρω.
Απλά πρέπει να διαλέξεις ανάλογα με την χρήση τι προτιμάς: scheduler ή shaper;
Δοκιμάζοντας την πρώτη λύση χωρίς bw limit είδα ότι υπάρχουν μεγάλες καθυστερήσεις σε περιπτώσεις τερματισμού της γραμμής.
Δοκιμάζοντας την δεύτερη είδα ότι το μόνο που χάνω είναι ο γρήγορος τερματισμός της γραμμής σε dw.
Το να μου κατέβει λίγο ποιο αργά το dw (torrent ή οτιδήποτε άλλο) είναι υποφερτό για εμένα.

Από μετρήσεις που έκανα είδα ότι τα drops δεν είναι άμεσα αντιοστρόφως ανάλογα με το delay.
Δηλαδή... ναι μεν θα δεις ότι αυξάνοντας τα drops έχεις μείωση του delay (και το αντίστροφο) αλλά όχι με το ίδιο ποσοστό.
Μια μικρή αύξηση των drops συνεπάγεται μεγάλη μείωση του delay.

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

[macro]

Δε διαφωνω.

Εγω τα εχω ολα unlimited και τα πακετα τα εχω φερει κοντα στα drops και αυτη η λυση μου παιζει μια χαρα.