Re: [Ecn-sane] [bbr-dev] duplicating the BBRv2 tests at iccrg in flent?

[Dave Taht <dave.taht@gmail.com>]

> With fq_codel and the same ECN marking threshold (fq_codel ce_threshold 242us), we see slightly smoother fairness properties (not surprising) but with slightly higher latency.
>
> The basic summary:
>
> retransmits: 0
> flow throughput: [46.77 .. 51.48]
> RTT samples at various percentiles:
>   %   | RTT (ms)
> ------+---------
>    0    1.009
>   50    1.334
>   60    1.416
>   70    1.493
>   80    1.569
>   90    1.655
>   95    1.725
>   99    1.902
>   99.9  2.328
>  100    6.414

I am still trying to decode the output of this tool. Perhaps you can
check my math?

At 0, I figure this is the bare minimum RTT latency measurement from
the first flow started, basically a syn/syn ack pair, yielding 9us, of
which gives a tiny baseline to/from the wire delay, the overhead of a
tcp connection getting going, and the routing overheads (if you are
using a route table?) of (last I looked) ~25ns per virtual hop (so *8)
for ipv4 and something much larger if you are using ipv6. This is
using ipv4?

A perfect level of interleave of 20 flows, 2 large packets each, would
yield a RTT measurement of around 532 extra us, but you are only
seeing that at the 80th percentile...

100: The almost-worst case basic scenario is that 20 flows of 64k
GRO/GSO bytes each are served in order. That's 13us * 42 * 20 =
10.920ms. It's potentially worse than that due to the laws of
probability one flow could get scheduled more than once.

1) What is the qdisc on the server and client side? sch_fq? pfifo_fast?

2) What happens when you run the same test with gso/gro disabled?