QoS σε Mikrotik

[neoplan]

Επειδή τις τελευταίες μέρες πέφτει πολύ χριστοπαναγία στην ώρα του gaming για lag καθώς το dc παίρνει φωτιά βρήκα αυτόν τον οδηγό για το πως να μπει QoS στο access point του mikrotik.

http://www.pwmn.net/wiki/index.php/Qual ... cess_Point

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

Tweety πιάσε δουλειά

[grigoris]

μιλας για lag οταν εχει traffic το AP οπου παιζουν και καποιοι clients ή οταν εχει το BB? Aν ισχυει το δευτερο τοτε δε χρειαζεσαι QoS, link της προκοπης θελεις! Για το πρωτο μιλαμ στο καναλι..

[neoplan]

Μιλάω πάντα για το ap. Το backbone δεν κολάει (εκτός αν κατεβάζεις εσύ απο μένα με 2,5ΜΒ που είμαστε στα 2 άκρα αλλά αυτό είναι άλλη ιστορία)

[neoplan]

Μετά απο πολύ χριστοπαναγία που άκουγα στο room για leecheria στον beat, πέρασα Quality of Service στο Access Point του.
Με απλό QoS και με προτεραιότητα που φαίνεται στον πίνακα εδώ (κάτω κάτω) παρατήρησα το εξής:

Code: Select all

C:\Users\laptoplan>ping 10.140.5.105

Pinging 10.140.5.105 with 32 bytes of data:
Reply from 10.140.5.105: bytes=32 time=703ms TTL=61
Reply from 10.140.5.105: bytes=32 time=578ms TTL=61
Reply from 10.140.5.105: bytes=32 time=465ms TTL=61
Reply from 10.140.5.105: bytes=32 time=681ms TTL=61

Ping statistics for 10.140.5.105:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 465ms, Maximum = 703ms, Average = 606ms

Ενώ μόλις έτρεξα ένα script που βάζει και limit ανάλογα με την προτεραιότητα είχαμε το εξής:

Code: Select all

C:\Users\laptoplan>ping 10.140.5.105

Pinging 10.140.5.105 with 32 bytes of data:
Reply from 10.140.5.105: bytes=32 time=99ms TTL=61
Reply from 10.140.5.105: bytes=32 time=5ms TTL=61
Reply from 10.140.5.105: bytes=32 time=24ms TTL=61
Reply from 10.140.5.105: bytes=32 time=6ms TTL=61

Ping statistics for 10.140.5.105:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 99ms, Average = 33ms

Το πρώτο σενάριο είναι Gaming_OFF με per connection queue και το δεύτερο είναι Gaming_ON με limit 10kb σε P2P, 100kb στις υπόλοιπες και 0 σε voip, games, www, https, webcache, icmp κτλ

Έχω βάλει schedule όπου τρέχει το script Gamin_On από τις 12 το μεσημέρι μέχρι τις τις 2 τη νύχτα.

Τα αποτελέσματα στην πράξη θα μας τα πεί ο iron. Αν κάτι τέτοιο λειτουργήσει καλό θα ήταν να το βάλουν όσοι έχουν πολυσύχναστο ap.

[sf1n4k1]

Ωραίος..για να το δούμε και στην πράξη ώστε να το προχωρήσουμε και αλλού.

[grigoris]

Παιζει ετσι, αλλα πιο σωστο ειναι να γινει το shapping με βαση κυριως στις ουρες και οχι στα limits.
To εχω εδω και πολυ καιρο στο ΑΡ του jester που ειχε προβλημα με το leechαρισμα, αλλα δεν ασχοληθηκε κανεις για να το ρεγουλαρει.

Η dota αφου δεν τρωει bandwidth μεγαλο και θελει μονο αποκριση μπορει να μπει μαζι με critical traffic οπως snmp,icmp,etc.. Μετα θελει λιιιγο ρεγουλαρισμα ομως αναλογα με το bandwidth του ΑΡ.

θα μου πεις γιατι το λες και δεν το φτιαχνεις...