Σε γενικές γραμμές όλα όσα ανέφερες συνεισφέρουν στην ποιότητα ενός link.
Για το SNR, όσο καλύτερο έχεις, τόσο πιο ανεκτικό θα μπορεί να είναι το link σε παρεμβολές.
Για το CCQ προσωπικά δεν κρατάω link που δεν έχει 100/100 (tx/rx) όταν κάνει full κίνηση up/down. Αν δεν είναι 100% και στις 2 πλευρές σημαίνει ότι κάνει retransmit πακέτα κλπ (άρα χάνεις σε ταχύτητα και αυξάνει το latency)
Για το latency προσωπικά κοιτάω να είναι κατά μέσο όρο μόνιμα στο 1ms. Αν lagάρει μόνιμα (πολύ) παραπάνω τότε θεωρώ πως το link δεν είναι καλό. Εξαρτάται βέβαια και από την κίνηση που περνάει. Προφανώς αν τελικιάζει το link θα έχει αυξημένο latency.
Γενικά το κατά πόσο παίζει καλά ένα link το βλέπεις συνδυαστικά τι latency σηκώνει σε συνδυασμό με το τι κίνηση μπορεί να περάσει both up/down.
Μάλιστα αν σε bandwidth tests με both up/down η μία μεριά (πχ receive) πιάνει περισσότερα απότι η άλλη (send) τότε παίζει το ένα άκρο να μην «ακούει» καλά (αυτό όμως μην το πάρεις και της μετρητοίς μιας και παίζει ρόλο και η CPU των 2 άκρων που τρέχουν το bandwidth test).
Ωστόσο βλέποντας απλά μία στιγμή το SNR, CCQ & max bandwidth δεν μπορείς να κρίνεις ένα link με ασφάλεια για το αν είναι καλό ή κακό.
Μπορεί την ώρα που κάνεις τις δοκιμές να μην παίζουν παρεμβολές, και την επόμενη στις 9 το πρωί κάποιο εταιρικό link να «ξυπνήσει» και να αρχίσει να σε σκίζει.
Κατά την προσωπική μου άποψη θες μόνιμο monitoring με τουλάχιστον smokeping (latency & packet loss measurements) και ένα cacti/mrtg να βλέπεις την κίνηση σε συνάρτηση με το lag από το smokeping.
Σαν έξτρα bonus θες και γραφήματα για το Signal, Noise, CCQ, link uptime.
Έχοντας τέτοιες μετρήσεις με μία απλή ματιά στα γραφήματα ξέρεις αμέσως αν έχει πρόβλημα κάτι.
Αν πχ δεις packet loss στο smokeping και την ίδια ώρα δεν υπάρχει κίνηση ή αλλαγή στο signal αλλά έχει πέσει το CCQ τότε το πιο πιθανό είναι να έχεις κάποια παρεμβολή από άλλο λινκ.
Αν πχ δεις αυξημένο latency ή/και packet loss και το σήμα έπεσε, τότε το πιο πιθανό είναι να έχασε κάποιος από τα 2 άκρα την στόχευση του.
Και άλλα τέτοια διάφορα σενάρια. Με τον καιρό μαθαίνεις να διαβάζεις τα γραφήματα και με μία ματιά ξέρεις τι φταίει στο link πριν καν μπεις στο RB να δεις
Τέτοια γραφήματα και μετρήσεις είχαν σχεδόν όλοι κάποτε στο AWMN και τα είχαν δημόσια διαθέσιμα. Αλλά από τότε που μάθαμε στα DNS πάνω στο Mikrotik, στα virtual APs, στο NV2 και στο άντε να βγάλουμε links όπως όπως είναι ελάχιστοι που κρατάνε πλέον στατιστικά και γενικά τα παρακολουθούν τακτικά.
Για μένα (και είναι προσωπική άποψη - αν παρεξηγηθεί κάποιος... ξυδάκι ) δεν νοείται σοβαρός κόμβος χωρίς να έχει τουλάχιστον ένα mrtg & smokeping (ή ότι αντίστοιχο υπάρχει και βολεύει τον καθένα) δημόσια διαθέσιμο για όλους (και ιδανικά πάνω στο domain-όνομα του κόμβου οπότε από το trace να μπορείς να ξέρεις που θα βρεις τα στατιστικά κάθε κόμβου - λέεεεεεμε τώρα....).
Όποιος τρέχει κόμβους χωρίς τα στοιχειώδη στατιστικά απλά δεν παίρνει στα σοβαρά την ευθύνη του σε όλους τους υπόλοιπους που θα τύχει να περάσουν από τον κόμβο του.
Δες πχ το
http://www.cha0s.awmn (pretty lame αισθητικά - αλλά κάνει την δουλειά - με την μία έχω εικόνα όλων των links μου)
Τώρα για το πως υπολογίζεται το CCQ μπορείς να δεις εδώ:
http://wiki.mikrotik.com/wiki/Manual..._determined.3F
Από σχεδιασμού αν δεις για να υπολογίσει το CCQ κοιτάει τα frames που περνάνε πόσο χρόνο παίρνουν και πόσα retries γίνονται κλπ.
Όταν ένα link δεν έχει κίνηση δεν έχει αρκετά data για να υπολογίσει σωστά το CCQ και έτσι εμφανίζει χαμηλότερα νούμερα.
Nothing to worry about δηλαδή
Άλλα πράγματα που καθιστούν καλό ένα link (για μένα τουλάχιστον ) είναι η χρήση nstreme όπου έχεις σχεδόν το διπλάσιο bandwidth με το ίδιο εύρος συχνότητας και έχεις αρκετά προβλέψιμο latency. Επίσης τα data rates ενός link πρέπει να είναι κλειδωμένα στο μέγιστο δυνατό που παίζουν σωστά (σε a link δεν δέχομαι οτιδήποτε πλην των 54Mbit ασυζητητί ) και να υπάρχει και ένα rate χαμηλότερο επιλεγμένο για τυχόν μικρο-παρεμβολές ώστε να μειώσει προσωρινά το bandwidth του το link παρά να πέσει τελείως ή να lagάρει άσχημα.
Τέλος στην εποχή του 802.11a θεωρούσα υποχρεωτική την χρήση traffic shaping. Ωστόσο τότε ακόμα παίζαμε με PCs για routers και έπαιζε άφθονη επεξ. ισχύ. Τώρα με τα RB και με n links των 100-150mbit το καθένα είναι ουσιαστικά αδύνατο με τις cpus που φοράνε (ολα τα RB για wireless links - μηδενός εξαιρουμένου).
Το καλό τουλάχιστον είναι πως με 100mbit (limited by ethernet - πχ σε ένα SXT) n link δεν lagάρει πάνω από 1-2ms με full κίνηση αφού το bottleneck γίνεται το ethernet αντί για το RF κομμάτι. Οπότε παίζει κάτι σαν self-traffic-shaping
