Excellent job Richard! Those slides are very clean and informative and you got fantastic real life user reports!<br>Point #1 is very common: lots of behind-the-scenes javascript, buffering, asynchronous requests, facebook chat box and updates, etc.<br>
<br>I was trying to make a mock conversation for the purpose of providing a story backing up the debloating efforts so that end users realize better what's going on. Please, guys, have a look and comment:<br><a href="https://soltysiak.com/wiki/index.php/BB_dialog">https://soltysiak.com/wiki/index.php/BB_dialog</a><br>
<br>Part 1 is an intro, also touching on tiered ISP services. Part 2 would be what bufferbloat is all about. Part 3 is an outro to have the users have a take-home message, also touching on DPI and other evil stuff ISPs do trying to workaround the issues.<br>
<br>You can edit that wiki.<br><br>I couldn't post it on <a href="http://bufferbloat.net">bufferbloat.net</a> wiki because I don't seem to have privilege to create new pages so I setup my own.<br><br>Regards,<br>Maciej<br>
<br><br><div class="gmail_quote">On Sun, Dec 9, 2012 at 5:56 PM, Richard Brown <span dir="ltr"><<a href="mailto:richard.e.brown@dartware.com" target="_blank">richard.e.brown@dartware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Folks,<br>
<br>
I gave the talk to the local Linux User Group on Thursday, and it went really well. Two people came up to me after the talk and said, in effect, "You know, I think I've seen this. But I've always blamed something else." Their experience:<br>
<br>
- Attempting to Skype with a bunch of web browser tabs open gives bad results. Closing the tabs made things better. (They been blaming the browser for "using too much memory". Now it's possible to think that it's a network problem.)<br>
<br>
- Another person reported that his network connection (wireless ISP, two hops to a wired network) seemed to work OK as long as his household was mostly downloading. But uploading much of anything really made things bad.<br>
<br>
I posted the slides at <a href="http://www.bufferbloat.net/attachments/download/148/Bufferbloat-DLSLUG-Dec2012.pdf" target="_blank">http://www.bufferbloat.net/attachments/download/148/Bufferbloat-DLSLUG-Dec2012.pdf</a><br>
<br>
Rich<br>
<br>
PS I've updated the CeroWrt site to include links to a bunch of relevant videos. (<a href="http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos" target="_blank">http://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos</a>) Please let me know if there are others that we should point to.<br>
<br>
On Nov 25, 2012, at 8:11 PM, Richard E. Brown <<a href="mailto:rbrown@intermapper.com">rbrown@intermapper.com</a>> wrote:<br>
<br>
> Folks,<br>
><br>
> I am planning to give a talk about Bufferbloat to the local Linux User Group next week (<a href="http://dlslug.org" target="_blank">http://dlslug.org</a>). All this traffic on the list is fantastic, because it gives me a lot of background on the current state of bufferbloat. I've pulled together a bunch of general questions about CeroWrt that I would like to be able to cover if they come up:<br>
><br>
> - Is it true that the latest CeroWrt is Sugarland 3.3.8-26 from mid-September? (My router is using this build - r33460.)<br>
><br>
> - I see the "QoS" item in the Network tab of the web GUI. Is this important for Sugarland? Or does some other router configuration take care of this now?<br>
><br>
> - What's the relationship between the QoS GUI item above and the debloat.sh and simple_qos.sh scripts that have been mentioned on this list? What's the best practice here for getting a router up and running?<br>
><br>
> - I can see how the CeroWrt de-bloating algorithms help protect against bad latency when I'm *uploading* big files. I'm not sure whether using CeroWrt with its CoDel/FQ/SFQ/etc. helps when I'm downloading big files, though. What can I say about this?<br>
><br>
> - I believe the default DNS server in Sugarland is dnsmasq, not bind. Is DNSSEC enabled by default? Also: there's a report (Bug #411) that says that DNS is leaking internal names to the outside world. What's the best advice for closing this? ("list notinterface 'ge00'" is one recommendation…)<br>
><br>
> - I've been assembling information about the various de-bloating techniques implemented in CeroWrt. It seems that Infoblox has recently reorganized their blogs, and the links published earlier this week have all broken. Here are updates:<br>
><br>
> <a href="http://www.infoblox.com/community/blog/application-analysis-using-tcp-retransmissions-part-1" target="_blank">http://www.infoblox.com/community/blog/application-analysis-using-tcp-retransmissions-part-1</a><br>
> <a href="http://www.infoblox.com/community/blog/application-analysis-using-tcp-retransmissions-part-2" target="_blank">http://www.infoblox.com/community/blog/application-analysis-using-tcp-retransmissions-part-2</a><br>
> <a href="http://www.infoblox.com/community/blog/router-buffer-tuning" target="_blank">http://www.infoblox.com/community/blog/router-buffer-tuning</a><br>
> <a href="http://www.infoblox.com/community/blog/rethinking-interface-error-reports" target="_blank">http://www.infoblox.com/community/blog/rethinking-interface-error-reports</a><br>
><br>
> My plan is to give a little of the science behind bufferbloat mitigation and also put in a plug for CeroWrt. Any topics I haven't already mentioned that I should? Thanks!<br>
><br>
> Rich Brown<br>
> Hanover, NH USA<br>
<br>
<br>
_______________________________________________<br>
Cerowrt-devel mailing list<br>
<a href="mailto:Cerowrt-devel@lists.bufferbloat.net">Cerowrt-devel@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cerowrt-devel" target="_blank">https://lists.bufferbloat.net/listinfo/cerowrt-devel</a><br>
</blockquote></div><br>