Re: [Cake] Cake tin behaviour - discuss....

["David P. Reed" <dpreed@deepplum.com>]

[-- Attachment #1: Type: text/plain, Size: 1838 bytes --]


Very interesting. However, I'm curious about what is being "ping'ed" from outside.
 
I would bet that the ping comes in on your router interface and is reflected immediately back. Which would mean that it might not at all be going through the Cake layer. That depends on the details of your setup, which you didn't share.
 
As you probably know, Cake works by packet shaping in the box where it runs, in the Linux stack. If the ping responder is on the ISP side of Cake, it will not be measuring lag-under-load *inside* cake.
 
End-to-end lag-under-load on multiple paths sharing a bottleneck is the problem Cake was invented to solve. (Jonathan - you agree?) Yes, it will move that congestion "inside" itself, pulling it out of the bottleneck itself. There it drops and ECN's "as if" the bottleneck were working correctly, rather than being "bufferbloated".
 
So it would be interesting to learn more about the topology of your test to interpret this ping.  A more interesting ping would be along the fujl path that the other flows are taking. Your ISP can't provide that.
 
 
On Saturday, April 25, 2020 5:31pm, "Kevin Darbyshire-Bryant" <kevin@darbyshire-bryant.me.uk> said:



> 
> 
> > On 25 Apr 2020, at 21:56, David P. Reed <dpreed@deepplum.com> wrote:
> >
> > Question: what's the "lag under load" experienced when these two loads are
> filling the capacity of the bottleneck router (the DSL link)?
> > I'm wondering whether your cake setup is deliberately building up a big queue
> within the router for any of the 10 bulk/best efforts flows.
> 
> https://www.thinkbroadband.com/broadband/monitoring/quality/share/3dec809ecef5cd52f574b6be5da9af28326845d6-25-04-2020
> 
> I don’t reckon it’s bad for the past 24 hours, one peak at 50ms. Avg
> latency increase by about 6ms during load.
> 
> 
> 

[-- Attachment #2: Type: text/html, Size: 3359 bytes --]