Re: [Cake] pie in dd-wrt

[Dave Taht <dave.taht@gmail.com>]

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.

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



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740