Am 21.08.2019 um 23:53 schrieb Dave Taht:
On Wed, Aug 21, 2019 at 2:40 PM Toke Høiland-Jørgensen <t...@redhat.com> wrote:
Dave Taht <d...@taht.net> writes:
Sebastian Gottschall <s.gottsch...@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.gottsch...@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
_______________________________________________
Cake mailing list
Cake@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cake
