Post a Comment On: I am mcgrof's smirking revenge

[Image]
At this point if you have not heard of bufferbloat and you work for a silicon company making networking hardware then it should explain why Jim Gettys and Kathleen Nichols have published an ACM paper on bufferbloat. I was only finally convinced on bufferbloat after the elaborate track on bufferbloat the Linux Plumbers conference in Santa Rosa, 2011. Let me make this crystal clear. Bufferbloat is not a "Linux issue", it affects all Operating Systems.

At this point the central development front for fixing bufferbloat (and modernizing other things) is on CeroWrt. Despite it being based on OpenWrt and this being a Linux distribution designed originally for 802.11 Access Points I want to make sure people are aware that not only is bufferbloat a complex problem as illustrated on the ACM paper but with regards to wireless we are entering uncharted territory and the issues are made even more complex with it. For example one mitigation factor is Byte Queue Limits (BQL patches are now merged upstream on the Linux development trees) but this does in no way consider 802.11's Point to MultiPoint possible topologies and how an Access Point may need to adjust its own, not only queue size, but also rate used to transmit frames. Consider also aggregation and how big your aggregates are and should be... Its not an easy problem to solve. One paper out there that did touch on 802.11 is Tianji Li's paper and one algorithm described there is eBDP. John Linville has implemented support for eBDP for on mac80211 but currently its design requires a bit more work to get upstream. John has noted that eBDP does follow some philosophical similarities to the minstrel rate control algorithm. The issues are so complex that I would expect no other philosophical approach to the problem. In a way, the minstrel philosophy parallels similar solutions to complex problems as illustrated by Tim Harford in his TED talk about the "God complex". I should note though that eBDP does not address aggregation though. There is a lot of room for improvement and research.
If you are still not convinced about bufferbloat I invite you to read my previous blog post about my own metrics. In short run Netalyzer while uploading (bittorrent, rsynch, scp) and look for the "Network buffer measurements" section. I encourage you to also run the test without uploading anything, at least for me I also get terrible results. If you are like me and share your 802.11 network with your neighbors or family you likely will have someone uploading something at any point in time, even if its small. Forget about a corporate environment where the 802.11 network is shared among many coworkers. This is also why I never use a coffee shop's 802.11 network even if its free, I get better performance over my cell phone's 4G and even 3G network, running my phone as a hotspot, than a shared 802.11 network at a coffee shop as my link is dedicated. If my phone had 5 GHz support I suspect I'd get even better results given that current phones only ship with 2.4 GHz 802.11 devices.