[Cake] cake flenter results round 0

[Dave Taht]

That is a really, really long, and extremely pleasant, way of saying:

 "OK, it doesn't crash".

:)

can flenter work with the veth stuff and namespaces?





On Sun, Nov 26, 2017 at 12:12 AM, Pete Heist <peteheist at gmail.com> wrote:
> I have a script (called flenter) which can run flent with different
> parameter variations and produce an html report. I’m very sorry again that
> this doesn’t yet use flent’s batch feature- it was started before I knew
> about that.
>
> I’ll use it to produce some “rounds” of cake tests, with notes/analysis of
> each round and plans for future rounds. If there’s any feedback on anything,
> results or what to change, let me know, otherwise I’ll just take it where
> I’m able to.
>
> I’m calling this round 0, because these tests weren’t designed originally
> for cake at all, but it’s a vastly stripped down version of tests I was in
> the middle of doing for point-to-point WiFi. The tests need a lot of changes
> for the next round to focus more on cake and those are noted at the end.
>
> Round 0 index of all tests:
>
> http://www.drhleny.cz/bufferbloat/cake/round0/
>
>
> *** Notes/Analysis ***
>
> * When “over-limited” to 200mbit, pfifo bloats everything, sfq improves the
> UDP flows but bloats TCP rtt, and cake clearly holds the lowest rtt for the
> ping/udp flows as well as TCP rtt, even when compared to fq_codel:
>
> http://www.drhleny.cz/bufferbloat/cake/round0/eg_csrt_rrulbe_eg_pfifo_200mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/eg_csrt_rrulbe_eg_sfq_200mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/eg_csrt_rrulbe_eg_fq_codel_200mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/eg_csrt_rrulbe_eg_cake_200mbit/index.html
>
>
> * At 950 mbit rate limiting, fq_codel holds latency of the ping and udp
> flows a bit lower than cake, whereas cake holds tcp rtt a bit lower. sfq
> does pretty well actually and pfifo is, well, pfifo:
>
> http://www.drhleny.cz/bufferbloat/cake/round0/eg_csrt_rrulbe_eg_pfifo_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/eg_csrt_rrulbe_eg_sfq_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/eg_csrt_rrulbe_eg_fq_codel_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/eg_csrt_rrulbe_eg_cake_950mbit/index.html
>
>
> * This is a little surprising, at 950mbit rate limiting with nflows 8/8,
> 16/16 and 32/32, fq_codel seems to outperform cake both in TCP rtt and
> latency of the UDP flows. Is cake’s “ethernet” keyword is really crucial
> here, or is there a difference between Cake and fq_codel at these high
> bandwidths? I’ll add it in my later tests. Also I’m losing the queue with
> 64/64 flows so will lower the bandwidth limit.
>
> http://www.drhleny.cz/bufferbloat/cake/round0/nflows_32_32_eg_pfifo_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/nflows_32_32_eg_sfq_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/nflows_32_32_eg_fq_codel_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/nflows_32_32_eg_cake_950mbit/index.html
>
>
> * Obviously cake (with diffserv3 and not besteffort), roundly defeats
> everything else in the torrent test because of the de-prioritization of the
> background flows:
>
> http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_eg_pfifo_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_eg_sfq_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_eg_fq_codel_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_eg_cakebe_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_eg_cake_950mbit/index.html
>
>
> * The benefit to lowering cake’s rtt parameter in an Ethernet environment
> can be seen on the TCP rtt:
>
> http://www.drhleny.cz/bufferbloat/cake/round0/cake_rtt_100ms_rrulbe_eg_cake_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/cake_rtt_60ms_rrulbe_eg_cake_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/cake_rtt_20ms_rrulbe_eg_cake_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/cake_rtt_10ms_rrulbe_eg_cake_950mbit/index.html
>
>
> * I’m a little surprised that fq_codel holds UDP flow latency a little lower
> at "target 1ms interval 10ms" than cake’s "rtt 10ms”. It almost seems like a
> trend that Cake outperforms at lower bandwidths and fq_codel at higher
> bandwidths.
>
> http://www.drhleny.cz/bufferbloat/cake/round0/fq_codel_ti_t5ms_i100ms_rrulbe_eg_fq_codel_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/fq_codel_ti_t3ms_i60ms_rrulbe_eg_fq_codel_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/fq_codel_ti_t2ms_i20ms_rrulbe_eg_fq_codel_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/fq_codel_ti_t1ms_i10ms_rrulbe_eg_fq_codel_950mbit/index.html
>
>
> * ECN helps marginally with UDP flow rtt, but I’ve never seen ECN do very
> much. When does it help the most?
>
> http://www.drhleny.cz/bufferbloat/cake/round0/ecn_off_rrulbe_eg_cake_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/ecn_on_rrulbe_eg_cake_950mbit/index.html
>
>
> * Cake’s “ethernet” parameter helps a bit, I’ll add it to all other rate
> limited tests in my next round:
>
> http://www.drhleny.cz/bufferbloat/cake/round0/cake_overhead_rrulbe_eg_cake_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/apu2-eth/cake_overhead_rrulbe_eg_cakeeth_950mbit/index.html
>
>
> * Cake’s host isolation clearly works, but I’m a little surprised that
> “srchost/dsthost” is more fair on a host level than
> “dual-srchost/dual-dsthost” (I usually find it easiest to just scroll to the
> bottom of the page and look at the numbers):
>
> http://www.drhleny.cz/bufferbloat/cake/round0/hostiso_eg_fq_codel_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/hostiso_eg_cake_src_cake_dst_950mbit/index.html
> http://www.drhleny.cz/bufferbloat/cake/round0/hostiso_eg_cake_dsrc_cake_ddst_950mbit/index.html
>
>
> * Anyone see anything in my “Flow Isolation Mix” tests? Those are a little
> hard to read. :) They used to be combined with a VoIP test but I don’t have
> a d-itg setup now.
>
>
> *** Round 1 Plans ***
>
> - Update cake to latest (will do this with every round)
> - Remove all “full-duplex limiting” (egress and ingress) tests as I don’t
> see the use here
> - Add cake’s “ethernet” keyword to all rate limited tests
> - Lower standard rate limit to 900mbit ensure no queue loss (particularly
> for nflows tests)
> - Take standard rrulbe tests to even lower bandwidths: 1mbit, 10mbit,
> 50mbit, 100mbit
> - Add bql tests (no rate limiting)
> - Add 100us, 1ms, 2ms, 3ms, 5ms, 8ms to Cake RTT tests
> - Add nflows tests at lower bandwidths
> - Fix UDP flood tests (no suitable iperf binary found)
> - Remove or improve flow isolation tests
> - Add ethtool output to host info
>
>
> *** Plans for Future Rounds ***
>
> - Add flow isolation tests with rtt variation (to look again at problem I
> reported in an earlier thread)
> - Use netem to make a spread of rtts and bandwidths (maybe the most useful
> of all?)
> - Add ack filtering tests
> - Add VoIP tests (I hope to do this with irtt)
> - Test BBR
> - Use qemu to test other archs (I may never get to this, honestly)
>
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619