[Bloat] Updates on www.bufferbloat.net

[Bloat] Updates on www.bufferbloat.net

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]

There has been a lot of work on the www.bufferbloat.net site. There are many small changes, and three new pages. As always, comments and PR's encouraged.

- Getting SQM Running Right - A revision of the original page from snapon.
https://www.bufferbloat.net/projects/cerowrt/wiki/Getting_SQM_Running_Right/

- Realtime Response Under Load (RRUL) Specification - A copy of the original Word document, reformatted to markdown. No editorial changes made. 
https://www.bufferbloat.net/projects/bloat/wiki/RRUL_Spec/

- RRUL Chart Explanation - RRUL charts seem a bit inscrutable when people first see them. This page could benefit from further explanation of BK, BE, CS5, etc. 
https://www.bufferbloat.net/projects/bloat/wiki/RRUL_Chart_Explanation/

- Updates to "Tests for Bufferbloat" - it's now focused primarily on various tests, not what to do about it.
https://www.bufferbloat.net/projects/cerowrt/wiki/Tests_for_Bufferbloat/

- Updates to "What to do about Bufferbloat" - Gives information about what you might do (leaving test descriptions on the previous page).
https://www.bufferbloat.net/projects/cerowrt/wiki/What_to_do_about_Bufferbloat/

Finally, here is a week of traffic info from the Cloudflare CDN. It appears that there are ~10-34k page views per day, averaging around 19k pages/day. More detail in the JSON below...

Rich


[-- Attachment #2: bufferbloat-net-last-week.json --]
[-- Type: application/json, Size: 19978 bytes --]

Re: [Bloat] Updates on www.bufferbloat.net

[moeller0]

[-- Attachment #1: Type: text/plain, Size: 3013 bytes --]

Hi Rich,

all of this is great, thanks!



> On Jul 7, 2016, at 17:12 , Rich Brown <richb.hanover@gmail.com> wrote:
> 
> There has been a lot of work on the www.bufferbloat.net site. There are many small changes, and three new pages. As always, comments and PR's encouraged.
> 
> - Getting SQM Running Right - A revision of the original page from snapon.
> https://www.bufferbloat.net/projects/cerowrt/wiki/Getting_SQM_Running_Right/
> 
> - Realtime Response Under Load (RRUL) Specification - A copy of the original Word document, reformatted to markdown. No editorial changes made. 
> https://www.bufferbloat.net/projects/bloat/wiki/RRUL_Spec/
> 
> - RRUL Chart Explanation - RRUL charts seem a bit inscrutable when people first see them. This page could benefit from further explanation of BK, BE, CS5, etc. 
> https://www.bufferbloat.net/projects/bloat/wiki/RRUL_Chart_Explanation/
> 
> - Updates to "Tests for Bufferbloat" - it's now focused primarily on various tests, not what to do about it.
> https://www.bufferbloat.net/projects/cerowrt/wiki/Tests_for_Bufferbloat/
> 
> - Updates to "What to do about Bufferbloat" - Gives information about what you might do (leaving test descriptions on the previous page).
> https://www.bufferbloat.net/projects/cerowrt/wiki/What_to_do_about_Bufferbloat/

	I see that there is a link to https://wiki.openwrt.org/doc/howto/sqm on this page, and that reminds me, could you add a link to https://github.com/moeller0/ATM_overhead_detector to that openwrt page please? Probably in the section titled “Link Layer Adaptation - the details…”
Here is a quick draft:

For true ATM links one often can measure the real per packet overhead empirically, see https://github.com/moeller0/ATM_overhead_detector for further information how to do that.

	And while at it the following might also need a small upgrade:
original: “SQM can also account for the overhead imposed by "Ethernet with overhead" (mostly VDSL) links. Cable Modem, Fiber, and direct Ethernet connections generally do not need any kind of link layer adaptation."

proposal: "SQM can also account for the overhead imposed by "Ethernet with overhead" (mostly VDSL) links. Cable Modems (docsis) are known to typically use 28 Byte of overhead in the upstream direction but only 14 in the downstream direction. If your version of SQM only supports to specify one value for the overhead, select 28 Bytes… Fiber, and direct Ethernet connections generally do not need any kind of link layer adaptation.”

	Thanks to Greg we learned something about docsis and it would be a pity not to pass this information on to our users… (Note to self I need to allow independent overhead control for ingress and egress in sqm-scripts and the GUI).

Best Regards
	Sebastian


> 
> Finally, here is a week of traffic info from the Cloudflare CDN. It appears that there are ~10-34k page views per day, averaging around 19k pages/day. More detail in the JSON below...
> 
> Rich
> 

[-- Attachment #2: bufferbloat-net-last-week.json --]
[-- Type: application/json, Size: 19978 bytes --]

[-- Attachment #3: Type: text/plain, Size: 149 bytes --]

> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Updates on www.bufferbloat.net

[Rich Brown]

Hi Sebastian,

> On Jul 7, 2016, at 11:55 AM, moeller0 <moeller0@gmx.de> wrote:
> 
> 	I see that there is a link to https://wiki.openwrt.org/doc/howto/sqm on this page, and that reminds me, could you add a link to https://github.com/moeller0/ATM_overhead_detector to that openwrt page please? Probably in the section titled “Link Layer Adaptation - the details…”
> Here is a quick draft:
> 
> For true ATM links one often can measure the real per packet overhead empirically, see https://github.com/moeller0/ATM_overhead_detector for further information how to do that.
> 
> 	And while at it the following might also need a small upgrade:
> original: “SQM can also account for the overhead imposed by "Ethernet with overhead" (mostly VDSL) links. Cable Modem, Fiber, and direct Ethernet connections generally do not need any kind of link layer adaptation."
> 
> proposal: "SQM can also account for the overhead imposed by "Ethernet with overhead" (mostly VDSL) links. Cable Modems (docsis) are known to typically use 28 Byte of overhead in the upstream direction but only 14 in the downstream direction. If your version of SQM only supports to specify one value for the overhead, select 28 Bytes… Fiber, and direct Ethernet connections generally do not need any kind of link layer adaptation.”
> 
> 	Thanks to Greg we learned something about docsis and it would be a pity not to pass this information on to our users… (Note to self I need to allow independent overhead control for ingress and egress in sqm-scripts and the GUI).

I took a stab at it. Let me know if I got it right: https://wiki.openwrt.org/doc/howto/sqm#sqmlink_layer_adaptation_tab

Thanks.

Rich