Re: [Cake] [Bloat] cake + mpls?

If you just want to use cake with priority tins based on the MPLS "Traffic Class" (TC) field (i.e. the renamed original "EXP" field, see RFC5462), I think you can use a tc flower filter ( https://man7.org/linux/man-pages/man8/tc-flower.8.html) matching on mpls_tc values. See here for some examples:

Re: [Cake] separate shaping of wifi

M Jonathan Morton wrote: > > On 4 Feb, 2019, at 12:04 am, Jonas Mårtensson < > martensson.jo...@gmail.com> wrote: > > > > I'm running OpenWrt with sqm on my home router. Is there any potential > problem with enabling sqm with cake on both eth0 (wan) and wlan0?

[Cake] separate shaping of wifi

I'm running OpenWrt with sqm on my home router. Is there any potential problem with enabling sqm with cake on both eth0 (wan) and wlan0? The reason for doing this is that if I only do shaping on the wan interface I still get bad uplink bufferbloat on wifi. I assume this is because the bottleneck in

Re: [Cake] State of the Cake speech...

Maybe not a changelog exactly but you can see commits to sch_cake here: https://github.com/dtaht/sch_cake/commits/master And the history for the kmod-sched-cake package in OpenWrt is here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=history;f=package/kernel/kmod-sched-cake/Makefile Each new

Re: [Cake] inbound cake or fq_codel shaping fails on cable on netflix reno

On Mon, Jul 23, 2018 at 4:56 PM Dave Taht wrote: > Great info, thx. Using this opportunity to rant about city-wid > networks, I'd have done something so different > than what the governments and ISPs have inflicted on us, substituting > redundancy for reliability. > > I'd have used bog standard e

Re: [Cake] lanman2018 cake talk ideas

On Thu, Jun 21, 2018 at 9:04 AM Pete Heist wrote: > > > On Jun 21, 2018, at 5:43 AM, Dave Taht wrote: > > > > I think your "megabit myth" idea (and language) would be a very > > powerful paper and/or talk to try and hammer home in multiple venues. > > > > I might spend a slide on it at this conf

Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed

I thought the discussion was only about GSO/TSO. Also, isn't GRO/LRO incompatible with routing? Anyway, I was just supporting your interpretation of what Eric potentially means. /Jonas On Thu, Apr 26, 2018 at 10:55 AM, Toke Høiland-Jørgensen wrote: > Jonas Mårtensson writes: > &g

Re: [Cake] CAKE upstreaming - testers wanted, ACK filtering rescuers needed

"I *think* that what Eric means is that the GSO logic should automatically size the GSO superpackets so the latency cost is negligible for the actual link rate." Something like this? https://lwn.net/Articles/564979/ https://lwn.net/Articles/564978/ /Jonas On Thu, Apr 26, 2018 at 9:34 AM, Toke

Re: [Cake] Testing variants of the MTU latency scaling

On Tue, Apr 24, 2018 at 9:22 PM, Kevin Darbyshire-Bryant < ke...@darbyshire-bryant.me.uk> wrote: > Assuming you’re using luci to configure then enabling both show and use > advanced configuration & show and use dangerous configurations… then enter > ‘ingress’ in the ‘advanced option string to pass

Re: [Cake] Testing variants of the MTU latency scaling

On Tue, Apr 24, 2018 at 1:45 PM, Toke Høiland-Jørgensen wrote: > Jonas Mårtensson writes: > > > One thing that is still not clear to me from these results: if I run > > cake on an IFB without ingress mode (i.e. the default?), does the MTU > > scaling have any impact on

Re: [Cake] Testing variants of the MTU latency scaling

One thing that is still not clear to me from these results: if I run cake on an IFB without ingress mode (i.e. the default?), does the MTU scaling have any impact on TCP download throughput? /Jonas On Sun, Apr 22, 2018 at 11:09 PM, Jonathan Morton wrote: > > Takeaways (see attached plots): > >

Re: [Cake] A few puzzling Cake results

On Wed, Apr 18, 2018 at 6:54 PM, Jonathan Morton wrote: > > On 18 Apr, 2018, at 7:11 pm, Toke Høiland-Jørgensen > wrote: > > > > What you're saying here is that you basically don't believe there are > > any applications where a bulk TCP flow would also want low queueing > > latency? :) > > I'm s

Re: [Cake] A few puzzling Cake results

Dave, in the thread referenced earlier that led to this change you said: "The loss of throughput here compared to non-ingress mode is a blocker for mainlining and for that matter, wedging this into lede." I'm curious, what would the latency be in Toke's experiment with non-ingress mode and with t

Re: [Cake] A few puzzling Cake results

On Wed, Apr 18, 2018 at 1:25 PM, Toke Høiland-Jørgensen wrote: > Toke Høiland-Jørgensen writes: > > > Jonathan Morton writes: > > > >>> On 17 Apr, 2018, at 12:42 pm, Toke Høiland-Jørgensen > wrote: > >>> > >>> - The TCP RTT of the 32 flows is *way* higher for Cake. FQ-CoDel > >>> controls TCP

Re: [Cake] A few puzzling Cake results

On Tue, Apr 17, 2018 at 2:22 PM, Toke Høiland-Jørgensen wrote: > Y via Cake writes: > > > From: Y > > Subject: Re: [Cake] A few puzzling Cake results > > To: cake@lists.bufferbloat.net > > Date: Tue, 17 Apr 2018 21:05:12 +0900 > > > > Hi. > > > > Any certain fomula of fq_codel flow number? > >

Re: [Cake] Cake not more CPU efficient than HTB+FQ-CoDel (anymore)?

wrong. I could have sworn > that I purged cake as a shaper from simple.qos when I created > piece_of_cake, but apparently that was just a fever dream... > > Sorry for the noise. > > > > On Apr 11, 2018, at 21:26, Sebastian Moeller wrote: > > > > > >

Re: [Cake] Cake not more CPU efficient than HTB+FQ-CoDel (anymore)?

On Wed, Apr 11, 2018 at 7:15 PM, Toke Høiland-Jørgensen wrote: > Jonathan Morton writes: > > >> On 11 Apr, 2018, at 6:24 pm, Toke Høiland-Jørgensen > wrote: > >> > >> So, um, did we cram so many features into Cake that it no longer uses > >> less CPU? Can anyone confirm these results? > > > > T