[Cerowrt-devel] Routing limit question

Sebastian Moeller moeller0 at gmx.de
Tue Oct 21 03:51:05 EDT 2014


HI Dave,


On Oct 21, 2014, at 00:48 , Dave Taht <dave.taht at gmail.com> wrote:

> OK, I tried a few combinations of burst and cburst on a cerowrt box,
> using 90/10 as a up/download speed.
> 
> burst 64000 cburst 64000 was a bit of a win, in most respects, but odd
> in others.
> 
> netperf-wrapper data at:
> 
> http://snapon.lab.bufferbloat.net/~d/burst_tests/

	Great, so I see an increase in ingress rate for cburst 64000 with no real side effects, but burst 64000 cburst 64000 somehow manages to punish one of the BE streams. Luckily the latency under load increase stays really small. Do you know whether sirq differed between the tests? (I assume no it should be pegged to 90-100% during all tests as the effective good put increased…)

Best Regards
        Sebastian

> 
> 
> On Mon, Oct 20, 2014 at 1:04 PM, Dave Taht <dave.taht at gmail.com> wrote:
>> On Sun, Oct 19, 2014 at 3:44 PM, Sebastian Moeller <moeller0 at gmx.de> 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 <dave.taht at gmail.com> wrote:
>>> 
>>>> Yes fiddling with burst seems to make sense. Try 16k
>>>> 
>>>> On Oct 19, 2014 11:56 AM, "Sebastian Moeller" <moeller0 at gmx.de> wrote:
>>>> HI Dave,
>>>> 
>>>> 
>>>> On Oct 19, 2014, at 20:24 , Dave Taht <dave.taht at gmail.com> 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 <ernestogelias at gmail.com> 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
>>>>>> Cerowrt-devel at lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Dave Täht
>>>>> 
>>>>> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
>>>>> _______________________________________________
>>>>> Cerowrt-devel mailing list
>>>>> Cerowrt-devel at lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Dave Täht
>> 
>> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> 
> 
> 
> -- 
> Dave Täht
> 
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks




More information about the Cerowrt-devel mailing list