cdfs help. I also try to encourage sending the flent.gz files too. :)

Outbound, to 99% or more of the rate, *with perfect framing* looks great so far, 'cept on crappy cablemodems.

I am concerned about recommending values as high as 98% for inbound shaping. We are engineering to

the test here (2? 3 flows? on a very short rtt), and need to leave *some* headroom for multiple flows to enter in slow start and get kicked out of it.

I'll buy that the old 85% figure made sense in the sub 20Mbit era, and that we only need enough headroom to allow X flows to enter based on the

characteristics of the link and typical traffic - 15 new flows per second * per active user/10 ? and cake's response to slow start is more agressive...

try a:

flent -H flent-london.bufferbloat.net -s .02 --te=download_streams=32 -t '98%' tcp_ndown

with htb+fq_codel and cake to see that spike more clearly.

On Tue, Jul 24, 2018 at 7:54 AM Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:

On 24 Jul 2018, at 14:51, Dave Taht <dave.taht@gmail.com> wrote:

Now that you can join the party, I note there IS a flent server in england with irtt on it.

flent-london.bufferbloat.net

Ok, well if you’re desperately interested….. :-)

Plot I did running to the london server, one shaped at 99% downstream, the other at 98%…. and I’ve decided to stick at 98% as a result - plot is a little bit hard to distinguish but I’d say there’s around 8ms avg less latency-ish between the two. And an order of magnitude between using london v fremont :-)

The upstream barely registers

# tc -s qdisc show dev ifb4eth0
qdisc cake 801a: root refcnt 2 bandwidth 78400Kbit diffserv3 dual-dsthost nat ingress split-gso rtt 100.0ms ptm overhead 26