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) One advantage of cake as cake as the shaper is it uses one allocation for all. hfsc -> cake/fq_codel/pie/etc, not so much. similarly, my old "plan" for a sch_mq_shaper (for hardware mq) was that the sub-qdiscs would all share the same bandwidth and memory allocation. >> >> Best Regards >> Sebastian >> >> >>> >>> Sebastian >>> >>> Am 21.08.2019 um 17:42 schrieb Dave Taht: >>>> this shows some good results with pie on the download >>>> >>>> >>> https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=313886&postdays=0&postorder=asc&start=30&sid=4d4d2a583afad73759cbeee1a8f4b329 >>>> _______________________________________________ >>>> 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 > _______________________________________________ > 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
