# Wi-Fi News > Τεχνολογία >  "Bufferbloat" - Έστω και λίγο QoS κάνει καλο

## NetTraptor

Μετά την Συνάντηση με τον Jim Gettys για δεύτερη φορά στην Βαρκελώνη αφού τον είχα ακούσει να διατυπώνει την θεωρία περί Bufferbloat σχεδόν 2 χρόνια πριν σε ένα Buttle Mesh σκέφτηκα ότι θα ήταν καλό να μοιραστώ κάποια άρθρα και Link που εκθειάζουν το καθόλα υπαρκτό πρόβλημα που επηρεάζει σχεδόν όλα τα είδη network hardware και όλα τα OS...

background : http://en.wikipedia.org/wiki/Bufferbloat

H παρουσίαση στην Βαρκελώνη: 



> Bufferbloat: Views of the Elephant
> Presenter(s): Jim Gettys
> Aules Aularis (A3) - A3 103
> VOIP and teleconferencing often perform much more poorly on today's Internet than the Internet of a decade ago, despite great gains in bandwidth. Lots of fiber, cheap memory, smart hardware, variability of wireless goodput, changes in web browser behaviour, changes in TCP implementations, and a focus on benchmarking Internet erformance solely by bandwidth, and engineer's natural reluctance to drop packets have conspired to encourage papering over problems by adding buffers; each of which may introduce latency when filled.
> The mistaken quest to never drop packets has destroyed interactivity under load, and often results in actual higher packet loss, as TCP's congestion avoidance algorithms have been defeated by these buffers. The lessons of the "RED manifesto" of 1997 have been forgotten or never learned by a new generation of engineers.
> Mesh networks are particularly sensitive to bufferbloat; each hop of the mesh may add delay under load.
> Solving bufferbloat require careful queue management that must be everywhere a queue may form. The publication of the new CoDel AQM algorithm finally gives us the tools to solve bufferbloat; but today's Linux's wireless driver structure limits its effectiveness; much work remains.



Λύσεις: 



> Είναι το δίκτυο σας γρήγορο, αλλά το download σας όχι; Μπορεί να μην φταίει ούτε ο πάροχός σας αλλά ούτε και ο server από τον οποίο κατεβάζετε, γιατί ενδιάμεσα παρεμβάλλονται πολλά buffers. Το πρόβλημα είναι παλιό αν και το όνομά του "bufferbloat" επινοήθηκε σχετικά πρόσφατα το 2010.
> 
> Σε ένα έγγραφο που δημοσιοποιήθηκε στο Association for Computing Machinery, δυο ερευνητές προτείνουν έναν νέο μηχανισμό διαχείρισης του queue (ουρά των πακέτων) που αντιμετωπίζει το πρόβλημα αυτό. Ο "Controlled Delay" (Ελεγχόμενης Καθυστέρησης) μηχανισμός, που προτάθηκε από την Kathleen Nichols από το Pollere και του Van Jacobsen από την Parc, έχει σχεδιαστεί για να παρέχει μία "no-knobs" προσέγγιση στην διαχείριση του queue ώστε να ξεπεραστεί το πρόβλημα του "bufferbloat" των δικτυακών συσκευών (routersκλπ).
> 
> Το πρόβλημα συνοψίζεται στο Bufferbloat Website ως: "Το buffering των πακέτων δημιουργεί μεγάλη καθυστέρηση (lag), jitter (ανώμαλο ρυθμό) αλλά και ελαττώνει την συνολική απόδοση του δικτύου."
> 
> Επειδή η μνήμη είναι φθηνή, εξηγούν οι Nichols και Jacobsen, κάθε κατασκευαστής υποθέτει πως το καλύτερο πράγμα είναι να κάνει τα buffers όσο πιο μεγάλα γίνεται για να διασφαλίσει ότι κανένα πακέτο δεν θα χαθεί. Αυτό όμως ακυρώνει τον πρωταρχικό σκοπό του buffering, που είναι η διαχείριση βραχυπρόθεσμων διακυμάνσεων στον ρυθμό εισερχόμενων πακέτων.
> 
> Συγκεκριμένα, αυτοί που υποστηρίζουν το Bufferbloat πιστεύουν ότι το πρόβλημα είναι στο άκρο: επειδή είναι πολύ δύσκολο να προβλέψεις το ιδανικό μέγεθος του buffer για π.χ. έναν DSL router, οι κατασκευαστές τείνουν να κάνουν το buffer όσο είναι δυνατόν μεγαλύτερο. Αυτό όμως ακυρώνει τον εγγενή μηχανισμό αντιμετώπισης συμφόρησης που έχει το TCP, ο οποίος βασίζεται σε πακέτα που απορρίπτονται για να μπορέσει να εντοπίσει τον ιδανικό ρυθμό για την εκάστοτε σύνδεση.
> ...


Project workspace http://www.bufferbloat.net/

----------

