Re: [Cake] Recomended HW to run cake and fq_codel?

> On Nov 27, 2017, at 7:28 PM, Jonathan Morton wrote: > An important factor when designing the test is the difference between > intra-flow and inter-flow induced latencies, as well as the baseline latency. > > In general, AQM by itself controls intra-flow induced latency, while flow > isolatio

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 10:08 PM, Toke Høiland-Jørgensen wrote: > > Yeah, the plot doesn't show up in the list because it's added > conditionally based on the data file. You have the choice of 'cpu', > 'cpu_bar' and 'cpu_box' for single test plots. These should show up in > the GUI when you load a

Re: [Cake] cake flenter results round 1

Pete Heist writes: >> On Nov 27, 2017, at 9:37 PM, Toke Høiland-Jørgensen wrote: >> >> If you add --test-parameter cpu_stats_hosts=localhost you will also get >> a graph of CPU usage which while somewhat rudimentary should at least >> make it possible to see from the results when you are runnin

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 9:37 PM, Toke Høiland-Jørgensen wrote: > > If you add --test-parameter cpu_stats_hosts=localhost you will also get > a graph of CPU usage which while somewhat rudimentary should at least > make it possible to see from the results when you are running out of CPU > entirely :

Re: [Cake] cake flenter results round 1

In the flent/misc dir are several faster polling routines written in C, also. On Mon, Nov 27, 2017 at 12:37 PM, Toke Høiland-Jørgensen wrote: >> I would not be surprised to find out that this result was also due to >> lack of CPU, since there’s a steady degradation in Cake’s performance >> above

Re: [Cake] cake flenter results round 1

> I would not be surprised to find out that this result was also due to > lack of CPU, since there’s a steady degradation in Cake’s performance > above 200mbit. Next time I’ll try 8/8 flows in addition. If you add --test-parameter cpu_stats_hosts=localhost you will also get a graph of CPU usage wh

Re: [Cake] cake flenter results round 1

I reran the test under different cake setup at the server. -- With "ethernet": qdisc cake 800f: root refcnt 2 bandwidth 900Mbit diffserv3 dual-dsthost rtt 100.0ms noatm overhead 38 via-ethernet mpu 84 Client A: avg median # data pts P

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 12:04 PM, Pete Heist wrote: > > * And then above 200mbit, fq_codel performs considerably better than cake at > the 32/32 flow tests. At 900mbit, UDP/ping is 1.1ms for fq_codel and 10ms for > cake. TCP RTT is ~6.5ms for fq_codel and ~12ms for cake. Dave’s earlier > explan

Re: [Cake] Recomended HW to run cake and fq_codel?

An important factor when designing the test is the difference between intra-flow and inter-flow induced latencies, as well as the baseline latency. In general, AQM by itself controls intra-flow induced latency, while flow isolation (commonly FQ) controls inter-flow induced latency. I consider the

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 7:13 PM, Dave Taht wrote: > > Pete Heist writes: > >>> On Nov 27, 2017, at 12:10 PM, Toke Høiland-Jørgensen wrote: >>> >>> Pete Heist writes: >>> * I wonder if the UDP flood tests really work at 900mbit: >>> >>> Did you set the UDP bandwidth? --test-parameter ud

Re: [Cake] cake flenter results round 1

Pete Heist writes: >> On Nov 27, 2017, at 12:10 PM, Toke Høiland-Jørgensen wrote: >> >> Pete Heist writes: >> >>> * I wonder if the UDP flood tests really work at 900mbit: >> >> Did you set the UDP bandwidth? --test-parameter udp_bandwidth=1000M for >> instance > > Aha, that’s undoubtedly th

Re: [Cake] cake flenter results round 1

I’m also finding out how simple it is to miss one little thing when looking at hundreds of test runs. Finding the “god metric” for rrul would make life easier... > On Nov 27, 2017, at 6:38 PM, Dave Taht wrote: > > On Mon, Nov 27, 2017 at 9:34 AM, Sebastian Moeller > wr

Re: [Cake] cake flenter results round 1

On Mon, Nov 27, 2017 at 9:34 AM, Sebastian Moeller wrote: > But 444.35 + 443.65 = 888, no? My bad. I miss-read the test setup. Pre-coffee here, though, that caused an adrenalin spike. Yea! per host fairness 1v12! and correct bandwidth on this cpu. :whew: > >> On Nov 27, 2017, at 18:33, Dave Tah

Re: [Cake] cake flenter results round 1

But 444.35 + 443.65 = 888, no? > On Nov 27, 2017, at 18:33, Dave Taht wrote: > > georgios > > the result you got was "fair", but you shoul have seen something > closer to 900mbit than 400. > > On Mon, Nov 27, 2017 at 8:17 AM, Georgios Amanakis > wrote: >> Dear Pete, >> >> I am trying to rep

Re: [Cake] cake flenter results round 1

Saw that too, but I think his test was only for download, with one client with 1 flow and the second client with 12, so the total of the two seems correct... > On Nov 27, 2017, at 6:33 PM, Dave Taht wrote: > > georgios > > the result you got was "fair", but you shoul have seen something > clos

Re: [Cake] cake flenter results round 1

georgios the result you got was "fair", but you shoul have seen something closer to 900mbit than 400. On Mon, Nov 27, 2017 at 8:17 AM, Georgios Amanakis wrote: > Dear Pete, > > I am trying to replicate the unfair behaviour you are seeing with > dual-{src,dst}host, albeit on different hardware an

Re: [Cake] cake flenter results round 1

Yes, especially since you’ve got higher-end hardware than I. 443.65mbit vs 444.35mbit looks pretty fair. :) Thanks for reproducing it. I’m going to have to review some of my flenter tests in light of this. I’m getting a handle on the limitations of the APU2 hardware. It’s quite good especially

Re: [Cake] cake flenter results round 1

Dear Pete, I am trying to replicate the unfair behaviour you are seeing with dual-{src,dst}host, albeit on different hardware and I am getting a fair distribution. Hardware are Xeon E3-1220Lv2 (router), i3-3110M(Clients). All running Archlinux, latest cake and patched iproute2-4.14.1, connected wi

Re: [Cake] Recomended HW to run cake and fq_codel?

> On Nov 27, 2017, at 4:54 PM, Sebastian Moeller wrote: > > how about keeping it simple and just give the latency increment under full > (bidirectional) link saturation (I guess a catchy acronym might be found)? > Yes this is a number where lower is better, but it also has immediate > informa

Re: [Cake] Recomended HW to run cake and fq_codel?

Well, how about keeping it simple and just give the latency increment under full (bidirectional) link saturation (I guess a catchy acronym might be found)? Yes this is a number where lower is better, but it also has immediate information (like: "mmmh, at an added 3seconds under load, VoIP might

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 3:48 PM, Jonathan Morton wrote: > It's not at all obvious how we'd detect that. Packets are staying in the > queue for less time than the codel target, which is exactly what you'd get if > you weren't saturated at all. > That makes complete sense when you put it that wa

Re: [Cake] cake flenter results round 1

It's not at all obvious how we'd detect that. Packets are staying in the queue for less time than the codel target, which is exactly what you'd get if you weren't saturated at all. - Jonathan Morton ___ Cake mailing list Cake@lists.bufferbloat.net https

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 3:07 PM, Pete Heist wrote: > >> On Nov 27, 2017, at 3:01 PM, Jonathan Morton > > wrote: >> Looking at the Cake stats for that run, it doesn't seem to have been >> signalling congestion at all, when you'd expect it to with 13 bulk flows >> run

[Cake] Fwd: new patchset for upstream net-next

-- Forwarded message -- From: Georgios Amanakis Date: Mon, Nov 27, 2017 at 9:27 AM Subject: Re: [Cake] new patchset for upstream net-next To: Sebastian Moeller > Groovy. Can you re-enable TSO/GSO/GRO? Of course! I have them disabled generally, not just for testing. > Just like

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 3:01 PM, Jonathan Morton wrote: > Looking at the Cake stats for that run, it doesn't seem to have been > signalling congestion at all, when you'd expect it to with 13 bulk flows > running through it. Something odd is going on there. > Ok, I’ll re-run this at a lower rate

Re: [Cake] cake flenter results round 1

Looking at the Cake stats for that run, it doesn't seem to have been signalling congestion at all, when you'd expect it to with 13 bulk flows running through it. Something odd is going on there. - Jonathan Morton ___ Cake mailing list Cake@lists.bufferb

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 1:18 PM, Jonathan Morton wrote: > Here's the difference between "srchost" and "dual-srchost": the latter > imposes per-flow fairness on traffic to each host, with a separate queue/AQM > per flow like with "flows". The former only has one queue/AQM per host. > > Analogous

Re: [Cake] Recomended HW to run cake and fq_codel?

> On Nov 27, 2017, at 1:04 PM, Jonathan Morton wrote: > My pet suggestion here is to represent latency as its inverse, > "responsiveness" with units of Hz. This has the dual advantages of bigger > numbers being better, and the figures being directly comparable with > framerates. > > As you s

Re: [Cake] cake flenter results round 1

Here's the difference between "srchost" and "dual-srchost": the latter imposes per-flow fairness on traffic to each host, with a separate queue/AQM per flow like with "flows". The former only has one queue/AQM per host. Analogously for dsthost. Then "hosts" mode allocates a separate queue for ea

Re: [Cake] Recomended HW to run cake and fq_codel?

My pet suggestion here is to represent latency as its inverse, "responsiveness" with units of Hz. This has the dual advantages of bigger numbers being better, and the figures being directly comparable with framerates. As you say, the methodology will need to be very carefully specified, so that w

Re: [Cake] dealing with multibit DUAL whatevers

This looks like a cosmetic change only (much easier to read now), but I was grokking this in case there would be something to explain the fairness differences in my dual-whatever tests, where srchost/dsthost is much fairer at a host level than dual-srchost/dual-dsthost (explained in round 1 resu

Re: [Cake] cake flenter results round 1

> On Nov 27, 2017, at 12:10 PM, Toke Høiland-Jørgensen wrote: > > Pete Heist writes: > >> * I wonder if the UDP flood tests really work at 900mbit: > > Did you set the UDP bandwidth? --test-parameter udp_bandwidth=1000M for > instance Aha, that’s undoubtedly the problem. Will do that next ti

Re: [Cake] cake flenter results round 1

Pete Heist writes: > * I wonder if the UDP flood tests really work at 900mbit: Did you set the UDP bandwidth? --test-parameter udp_bandwidth=1000M for instance -Toke ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listin

[Cake] cake flenter results round 1

http://www.drhleny.cz/bufferbloat/cake/round1/ Round 1 Tarball: http://www.drhleny.cz/bufferbloat/cake/round1.tgz Round 0 Tarball (previous run): http://www.drhleny.cz/bufferbloat/cake/round0.t

Re: [Cake] 950mbit result

> On Nov 27, 2017, at 9:42 AM, Dave Taht wrote: > > way more tcp rtt for cake > > http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_fd_cake_950mbit/rrul_torrent-tcp_rtt_cdf.svg > > v > > http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_fd_fq_codel_950mbit/rrul_torrent-tcp_rtt

[Cake] 950mbit result

way more tcp rtt for cake http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_fd_cake_950mbit/rrul_torrent-tcp_rtt_cdf.svg v http://www.drhleny.cz/bufferbloat/cake/round0/tor_rrultor_fd_fq_codel_950mbit/rrul_torrent-tcp_rtt_cdf.svg -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.co

Re: [Cake] Recomended HW to run cake and fq_codel?

>What I see as short term posibiliteis for us as ISP's is to push our vendors >to include this as a part of the feature set. We also could do >better with >the maketing. Lets steal an idea from the Video area. HD is often written as >1080P@60. Why not do the same for internet >speed? 60M@80