Re: [Cake] pie in dd-wrt

[Sebastian Gottschall <s.gottschall@newmedia-net.de>]

Am 21.08.2019 um 23:53 schrieb Dave Taht:
> On Wed, Aug 21, 2019 at 2:40 PM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>> Dave Taht <dave@taht.net> writes:
>>
>>> Sebastian Gottschall <s.gottschall@newmedia-net.de> writes:
>>>
>>>> Am 21.08.2019 um 18:21 schrieb Sebastian Moeller:
>>>>> On August 21, 2019 6:12:03 PM GMT+02:00, Sebastian Gottschall <s.gottschall@newmedia-net.de> wrote:
>>>>>> thats rather old. i rewrote all the qos code in the last 4 or 5 days.
>>>>>> so
>>>>>> things might be changed. next phase is bringing all the link level
>>>>>> detail configuration stuff into the gui which will be done
>>>>>> tomorrow or at least still within this week.
>>>>>> i also added now cake to some smaller low budged routers with limited
>>>>>> resources, so see how it runs. i had bad experiences with fq_codel in
>>>>>> the past due some high memory usage.
>>>>>> especially since its hard coded somewhat into the wireless ath9k
>>>>>> driver.
>>>>>> so i already modded it for more efficient handling. 4 mb max per queue
>>>>>> is simply too much for  a 32 mb ram based router.
>>>>> This is why I'm sqm we reduced the queued packet maximum m to around 1000, and also why cake has an explicit memlimit keyword.
>>>> yeah but does this help if fq_codel is hardcoded into mac80211?
>>>> fq_codel has a memlimit  keyword too btw. its fixed to 4MB. i reduced
>>>> it to 256kb on low memory architectures. no other way to get around
>>>> OOM problems
>>>> mac80211  does always make use of fq_codel. it has a own build in
>>>> implementation
>>> Certainly memory limits are a huge problem throughout complex qdiscs,
>>> especially when stacked up (eg hfsc 1 -> qdiscx hfsc 2 -> qdisc x),
>>> and
>>>
>>> OOMs suck. Particularly as few test packet flooding their devices
>>> after setting up a complex qdisc system.
>>>
>>> Bytes = time. It doesn't matter how many queues you have. This
>>> to me has always been one of the biggest flaws of the tc subsystem
>>> in general is that the total amount of memory in use on
>>> a given physical interface should be managed by the topmost layer.
>>>
>>> Same problem for wifi in multiple SSIDs... it's still just one device.
>>>
>>> However we do need enough bytes to keep the device busy and there
>>> are other problems with per packet limits leading me to prefer
>>> using just memory limits. One is, that your typical ack packet
>>> coming off the rx ring is actually 2k in size, not 64 bytes.
>>> I had at one point (in openwrt) something that took small packets
>>> and copied them to a smaller allocation which took pressure off the
>>> memory allocator.
>>>
>>> I've kind of lost track, did the ath9k wifi stuff use 1 allocation for
>>> all 4 hw queues? I'm afraid to look this morning... (and I'm not big
>>> on the 4 hw queues either)
>> The memory limit in mac80211 is global per phy.
> yea! win! So much better than four instances per ssid.
bad of some devices have 2 phys and still just 32 mb ram. i mean the 4 
mb limit i was talking about is just a mod by openwrt. the original 
default is 32 mb for fq_codel in mac80211.

>
>> -Toke
>> _______________________________________________
>> Cake mailing list
>> Cake@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cake
>
>