Yes, I know. In cake without ingress each *flow* gets 0.19mbit/s while
with ingress 0.12mbit/s. Multiplying this x11flows x4servers it gives
8.36mbit/s without ingress vs 5.2mbit/s with ingress. 

This was done in diffserv3 mode. I had hoped than Jonathan's latest
adjustment of failsafe ingress would have ameliorated this.
Nevertheless latency is unnoticeable.

If one decreases the number of flows, the difference becomes smaller.
This is why I had proposed that perhaps the failsafe ingress adjustment
should be done according to the number of the flows and not blindly.


George


On Mon, 2017-12-04 at 16:06 -0800, Dave Taht wrote:
> The puzzling thing about that graph is that you are only achieving
> 1.3
> mbit in the ing case.
> 
> On Mon, Dec 4, 2017 at 2:30 PM, Georgios Amanakis <gamanakis@gmail.co
> m> wrote:
> > I tried to simulate a situation resembling Windows
> > updates/Steam/Torrents on a slow 10/2mbit connection.
> > 
> > veth setup, 1 client, 4 servers
> > setup.tgz:
> > ./vsetup.sh
> > ./sshd.sh
> > ./vcake.sh
> > ./mm.sh
> > 
> > servers   --   delay   --   isp   --   mbox   --   client
> > (4)            20ms      10/2mbit    9/1.8mbit     (1)
> > 
> > The client is creating in parallel 11 downstream and 2 upstream
> > flows
> > to *each* of the 4 servers.
> > This was done by running 4 rrul_be_nflows tests in parallel.
> > 
> > Cake vs HTB/fqcodel at mbox.
> > Cake tested with ack-filter and ingress/egress.
> > 
> > Cake ingress, as expected, achieves better latency at the cost of
> > bandwidth. This does wonders on slow connections like mine.
> > 
> > I will try to increase the number of clients to 4 and run some
> > tests.
> > 
> > George
> 
> 
>