Re: [Cake] cake flenter results round 0

[Pete Heist <peteheist@gmail.com>]

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


> On Nov 26, 2017, at 7:19 PM, Dave Taht <dave@taht.net> wrote:
> 
> Pete Heist <peteheist@gmail.com <mailto:peteheist@gmail.com>> writes:
> 
> I think you can safely drop pfifo from future tests.

Yeah, done, chuckled at that actually. I was using pfifo as the “cold pool”.

> I'd rather like combined charts so it is possible to eyeball these
> differences directly. Just between fq_codel and cake. Or, is there a
> tarball available to browse this stuff?

Oh I know, I wanted to make the script do “combination plots” at the end but never got to it. I’ll try to make an archive available next time. Meanwhile I just open up run pages in multiple browser tabs and keyboard shortcut between them. Tests the visual memory.

BTW each run links to the .flent.gz file, but if you want to review more runs at once it's a pain to download each of them...

> Another nice thing to try capturing is queue depth/loss/marks/etc, which
> is --test-parameter qdisc_stats_hosts=X,y,z and qdisc_stats_interfaces=

You probably saw the `tc -s` output on teardown right? But can check out the test param...

> There's also capturing the tcp statistics on the server that is
> possible.

I do —socket-stats and have TCP RTT plots, but you mean something beyond that?

>> * 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.
> 
> Since fq_codel supports superpackets and cake peels them, we have a cpu
> and latency hit that originates from that. Also the codel derived
> algorithm in cake differs quite significantly from mainline codel, and
> my principal gripe about it has been that it has not been extensively
> tested against higher delays.

Ok, next run is going to show lower bandwidths with nflows=32/32 and I think cake is really going to shine there.

>> * 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.
> 
> I look forward to you adding OWD irtt based tests.

Me too, going to try to get that in soon...

>> *** 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?)
> 
> Yes.

Thought so, that didn’t make it into round 1 but asap after that. Round 1 just kicked off for the night. I got most of the changes I wanted in but only had an hour on it today so nothing more...

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