Re: [Cake] Fwd: ack filter rrul result at 200/10

Hi Dave, EdgeRouter X running OpenWrt 19.07.4, shaping to 112/20 qdisc cake : dev eth0.2 root refcnt 2 bandwidth 20Mbit diffserv3 dual-srchost nat wash ack-filter-aggressive split-gso rtt 100.0ms noatm overhead 26 mpu 64 fwmark 0x3 Sent 391625627749 bytes 493756837 pkt (dropped 4534914,

Re: [Cake] Frontier FIOS Framing

On Mon, 23 Sep 2019 at 13:56, Jonathan Morton wrote: > > The overhead compensation matters more with small packets than with the > larger ones used for bulk transfers; for the latter, reserving a little more > bandwidth will appear to make everything work. For fibre I would try > "ethernet"

Re: [Cake] act_conndscp

On Tue, 2 Apr 2019 at 00:37, Kevin Darbyshire-Bryant wrote: > > > > > On 23 Mar 2019, at 18:35, Kevin Darbyshire-Bryant > > wrote: > > > > > > > >> On 22 Mar 2019, at 21:24, Kevin Darbyshire-Bryant > >> wrote: > >> > >> It looks like act_conndscp has been shot down by the kernel people, at >

Re: [Cake] act_conndscp

On Wed, 20 Mar 2019 at 07:57, Kevin Darbyshire-Bryant wrote: > > > > > On 19 Mar 2019, at 21:24, Ryan Mounce wrote: > > > > Hi Kevin, > > > > I've finally applied your patches, compiled, and flashed on my router. > > Could you share your tc filter a

Re: [Cake] act_conndscp

Hi Kevin, I've finally applied your patches, compiled, and flashed on my router. Could you share your tc filter action for conndscp to get me started? -Ryan On Wed, 20 Mar 2019 at 06:39, Kevin Darbyshire-Bryant wrote: > > I’m not looking forward to the response/s from upstream but we shall see

Re: [Cake] Using firewall connmarks as tin selectors

On Mon, 4 Mar 2019 at 17:01, Jonathan Morton wrote: > …icing? Perfect! And to me, this functionality truly is the icing on (the) cake that makes it the complete bufferbloat/QoS system I've been dreaming of for ingress. ___ Cake mailing list

Re: [Cake] Using firewall connmarks as tin selectors

On Sun, 3 Mar 2019 at 22:22, Kevin Darbyshire-Bryant wrote: > > Be afraid, be very afraid. > > I’ve woken up with two ideas in my head, one is bad, the other is very bad. > The bad one is already implemented and lurking in the mine branch of my cake > git tree: > > The bad idea: > > An

Re: [Cake] Upstream submission of dual-mode fairness patch

On Mon, 4 Mar 2019 at 13:47, Jonathan Morton wrote: > > > On 4 Mar, 2019, at 4:55 am, Georgios Amanakis wrote: > > > > …the fairness logic wouldn't account for that "ingress traffic" and would > > yield fairer results. > > Well there we have a quandary, since presently it enforces fairness of

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

On 24 July 2018 at 11:59, Dave Taht wrote: > On Mon, Jul 23, 2018 at 7:17 PM Ryan Mounce wrote: >> >> > On 24 July 2018 at 00:14, Dave Taht wrote: >> >> what does the fast.com test do to you with and without inbound shaping >> >> on your link? >>

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

latency peaks around 40ms, then quickly settles down to 8ms. On multiple runs of the test, the worst latency peak I saw was 60ms. So even shaping ingress close to link capacity is a huge win against a FIFO. Regards, Ryan Mounce r...@mounce.com.au 0415 799 929 On 24 July 2018 at 00:14, Dave Taht

Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter

On 18 May 2018 at 13:38, Eric Dumazet <eric.duma...@gmail.com> wrote: > > > On 05/17/2018 07:36 PM, Ryan Mounce wrote: >> On 17 May 2018 at 22:41, Toke Høiland-Jørgensen <t...@toke.dk> wrote: >>> Eric Dumazet <eric.duma...@gmail.com> writes: >>>

Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter

On 17 May 2018 at 22:41, Toke Høiland-Jørgensen wrote: > Eric Dumazet writes: > >> On 05/17/2018 04:23 AM, Toke Høiland-Jørgensen wrote: >> >>> >>> We don't do full parsing of SACKs, no; we were trying to keep things >>> simple... We do detect the presence

Re: [Cake] Hopefully fixed ACK filter for v6

On 29 April 2018 at 07:19, Toke Høiland-Jørgensen wrote: > Think I finally managed to fix the ACK filter so it works for both 6in4 > and regular v6 (the latter seems to have been broken since the commit > "e6b72c2 ack_filter: make less aggressive by default" which accidentally >

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

> On 26 Apr 2018, at 16:09, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > > Ryan Mounce <r...@mounce.com.au> writes: > >> I'll investigate making the ACK filtering code safe, it is my mess after all >> :) >> >> Eric obviously understands t

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

filtering part of a split GSO super-packet? Regards, Ryan Mounce r...@mounce.com.au 0415 799 929 On 26 April 2018 at 06:15, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > For those who have not been following the discussion on the upstreaming > patches, here's an update: > >

Re: [Cake] overheads or rate calculation changed?

On 4.9 I am seeing a max_len equal to my IP MTU of on PPPoE interfaces, for both egress (hard_header_len = 26) and ingress via ifb (hard_header_len = 14). At least this issue had been offset by the double-overhead bug for a little while :) Regards, Ryan Mounce On 23 December 2017 at 23:25

Re: [Cake] set filtered acks to bulk mode

This appears to panic (and has, very indirectly, caused my LEDE router to wipe itself). Will take a closer look later. Regards, Ryan Mounce On 6 December 2017 at 08:30, Dave Taht <dave.t...@gmail.com> wrote: > The attached patch attempts to deprioritize bulk ack flows in cake. > >

Re: [Cake] [PATCH 2/3] Add Common Applications Kept Enhanced (sch_cake) qdisc

ces a combination of iptables, tc filter, htb and fq_codel in >> the sqm-scripts, with sane defaults and vastly easier configuration. >> >> Cake's principal author is Jonathan Morton, with contributions from >> Kevin Darbyshire-Bryant, Toke Høiland-Jørgensen, Sebastian Moel

[Cake] TCP ACK filtering

to others. Regards, Ryan Mounce ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake

Re: [Cake] overhead and mpu

On 6 September 2017 at 05:49, Dennis Fedtke wrote: > Hi! > > Thank you for all answers. > But for me this still makes no sense. > Assuming we have an ethnernet connection running over a docsis line. > docsis is able to transmit full 1500byte ethernet packets. > Lets say it

Re: [Cake] overhead and mpu

head and mpu. That's why it's there, so that nobody else ever has to go through the pain I did when fine-tuning cake for my DOCSIS connection. Regards, Ryan Mounce On 5 September 2017 at 15:30, Dennis Fedtke <dennisfed...@gmail.com> wrote: > Hi Ryan, > > Thanks for you answers. >

Re: [Cake] overhead and mpu

September 2017 at 12:56, Ryan Mounce <r...@mounce.com.au> wrote: > Hi Dennis, > > I am probably qualified to answer your question as I have done > extensive testing for this case with DOCSIS modems, indeed I was > prompted to contribute the 'mpu' option to cake in order to optimise &

Re: [Cake] overhead and mpu

, thus 64 bytes is our MPU for DOCSIS. It doesn't matter what packet size cake 'sees' on an interface, the overhead specified at the command line (directly or via keywords) is always interpreted relative to IP packets rather than relative to the PDU of a given interface. Regards, Ryan Mounce On 5