On Sun, Oct 19, 2014 at 3:44 PM, Sebastian Moeller <[email protected]> wrote: > Hi Dave, > > so I just went with what I have available, shaping between linux host on se00 > and macbook on sw10, shaper on se00 (25M/25M that is the maximum wireless > throughput with the current router position): burst/cburst set at > 1600(default) 16000 and 16000. And lo and behold the sirq gets smaller the > larger burst/cburst is set. Now tho test is just too confounded by my bad > wireless to be proof, but it certainly justifies the time to expose knobs in > the GUI to set burst/cburst/quantum values for HTB for each shaper instance > independent for ingress and egress… (I do not assume that this will even > double the throughput of a wndr as a router, but even just 10-20% will make a > difference ;) (I will eat my own dogwood, since I am about to upgrade from > 16M/2.5M to 50M/10M right into where our sirq pain starts)).
I don't necessarily think knobs need to be exposed. Perhaps tuning the burst parameter as a function of the induced latency would be about right. At 10mbits, a single 1500 byte packet takes 1.3ms to egress. So if we were to aim for .5-2ms worth of burst across the operational range of the shaper, that might work. In the case of cable, a grant request takes 2-6ms, anyway. So at 80mbit, a burst size of 8-16k seems possibly optimal. It could be higher (other overheads in the kernel). Now that we have a knob to jiggle, I'll go jiggle it when I have some time... I note that I'm under the impression cburst can be twiddled with also to make "powerboost"'s behavior better, but I've not seen it work. > > > > Best Regards > Sebastian > > On Oct 19, 2014, at 21:27 , Dave Taht <[email protected]> wrote: > >> Yes fiddling with burst seems to make sense. Try 16k >> >> On Oct 19, 2014 11:56 AM, "Sebastian Moeller" <[email protected]> wrote: >> HI Dave, >> >> >> On Oct 19, 2014, at 20:24 , Dave Taht <[email protected]> wrote: >> >> > On at least one verizon device I've tried it appeared that they had >> > SFQ or something similar on egress from the modem. >> > >> > http://www.bufferbloat.net/projects/codel/wiki/RRUL_Rogues_Gallery#Verizon-FIOS-Testing-at-25Mbit-up-and-25Mbit-down >> > >> > So you only needed to shape the download. which is good as we start >> > peaking out at 50Mbit download total. But only measurements can tell. >> >> So on Hnymans community openwrt build a few fortunate ones on >> excellent lines seem to get decent results even at 110-120 Mbps combined: >> https://forum.openwrt.org/viewtopic.php?pid=250989#p250989 >> and: >> https://forum.openwrt.org/viewtopic.php?pid=251013#p251013 >> I have no idea why and both lines were reasonably well-behaved even without >> any AQM/QOS... >> >> Also I wonder whether when we increase the quantum for higher rates to give >> HTB some breathing room, whether we also should increase burst and cburst? >> My hunch is that quantum affects the switching between the leaves, while >> busts and cburst should allow to dump more data to lower layers inside each >> leaf qdisc. And since we are running behind, maybe taking a bigger shovel >> can help some. (I assume this needs to be titrated not to kill latency under >> load, but if we can only effective have HTB execute x times per second we >> can easily afford to dump line-rate/maxHTB_iteratin_rate bytes per >> opportunity, no?) My own internet link is way to slow to test this... >> >> Best Regards >> Sebastian >> >> > >> > >> > On Sun, Oct 19, 2014 at 10:51 AM, Ernesto Elias <[email protected]> >> > wrote: >> >> Hello everyone! >> >> I have a question about the wndr3800 routing limit. I went back to the >> >> older >> >> submissions to see if I can find what would be the answer for it. But in >> >> my >> >> search I haven't managed to find a definite answer. From what I seen about >> >> setting the limit it can do with SQM is 50, 60, or 80 mbit. I'm just >> >> wondering if anyone can shed some light for me here as I have verizon fios >> >> and my speeds are 50 dl/50 ul. Thank you guys very much! >> >> >> >> _______________________________________________ >> >> Cerowrt-devel mailing list >> >> [email protected] >> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> >> > >> > >> > >> > -- >> > Dave Täht >> > >> > thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks >> > _______________________________________________ >> > Cerowrt-devel mailing list >> > [email protected] >> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
