On Wed, Aug 21, 2019 at 2:40 PM Toke Høiland-Jørgensen <[email protected]> wrote: > > Dave Taht <[email protected]> writes: > > > Sebastian Gottschall <[email protected]> writes: > > > >> Am 21.08.2019 um 18:21 schrieb Sebastian Moeller: > >>> > >>> On August 21, 2019 6:12:03 PM GMT+02:00, Sebastian Gottschall > >>> <[email protected]> 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. > -Toke > _______________________________________________ > Cake mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cake -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
