Re: [Cake] Simple metrics

I know I am simple minded, but still... I think that giving the RTT increase incurred on a sparse flow during full up- and downstream saturation seems the rawest and most useful; I guess one would need to select the number of concurrent flows and define sparseness. This will show the effect of f

Re: [Cake] cake flenter results round 2

> On Nov 29, 2017, at 4:42 AM, Georgios Amanakis wrote: > > @Pete I think you need to start netserver on the client first (in your case, > you are running flent on the server): "ip netns exec client netserver" Thanks. I think I’m going to have more success testing at much lower rates than you

Re: [Cake] cake flenter results round 2

> On Nov 29, 2017, at 9:19 AM, Pete Heist wrote: > >> On Nov 29, 2017, at 4:42 AM, Georgios Amanakis wrote: >> >> @Pete I think you need to start netserver on the client first (in your case, >> you are running flent on the server): "ip netns exec client netserver" > > Thanks. I think I’m goi

Re: [Cake] Cake tree unreadable

Dave Taht writes: > A flag day here is feasible. I will fiddle along the lines you > describe. FWIW I don't think the history is that bad. Sure, there are a bunch of merge commits, but picking out the real ones is not that difficult (unless you are using the github web interface, I guess, but th

Re: [Cake] Cake tree unreadable

Hi All, > On Nov 28, 2017, at 23:37, Dave Taht wrote: > > > A flag day here is feasible. I will fiddle along the lines you describe. > > As for other flag days... > > I'm toying with the idea of fixing xstats in a separate branch. I really > hate the idea of breaking backward compatability h

Re: [Cake] cake flenter results round 2

With ack-filter-aggressive I get results similar to rrul1 in ~10% of the runs, 90% are similar to rrul2. With ack-filter I haven't managed yet to get a rrul1 result, all of them are similar to rrul2. Will experiment more today. George On Tue, Nov 28, 2017 at 11:01 PM, Dave Taht wrote: > the ast

Re: [Cake] cake flenter results round 2

I am troubled by the number of data points flent reports for some pings and uploads in this setup. A typical ack-filter result, similar to rrul2 I posted before, looks like this: Summary of rrul test run 'rrul_cakeeth_ds3_900mbit_45mbit_ack' (at 2017-11-29 14:37:5 5.719180):

Re: [Cake] cake flenter results round 2

Georgios Amanakis writes: > I am troubled by the number of data points flent reports for some pings and > uploads in this setup. A typical ack-filter result, similar to rrul2 I > posted before, looks like this: > Summary of rrul test run 'rrul_cakeeth_ds3_900mbit_45mbit_ack' (at > 2017-11-29 14:3

Re: [Cake] cake flenter results round 2

> On Nov 29, 2017, at 3:50 PM, Toke Høiland-Jørgensen wrote: > > Georgios Amanakis mailto:gamana...@gmail.com>> writes: > >> I am troubled by the number of data points flent reports for some pings and >> uploads in this setup. A typical ack-filter result, similar to rrul2 I >> posted before, lo

Re: [Cake] cake flenter results round 2

> (That was also informative for me about how netperf decides when to > emit a data point…) In that case I can add that the stated reason for this way of doing things is performance (i.e., emitting data points should not interfere with transfer performance). This is mostly an issue on systems wher

Re: [Cake] cake flenter results round 2

I did some more testing. Same setup as before, I varied the amount of delay: server--delay--mbox--client netserver Xms/Xms 45/900mbit Cake config: qdisc cake 801b: dev mbox.l root refcnt 2 bandwidth 45Mbit diffserv3 triple-is

Re: [Cake] cake flenter results round 2

> On Nov 29, 2017, at 4:44 PM, Toke Høiland-Jørgensen wrote: > >> (That was also informative for me about how netperf decides when to >> emit a data point…) > > In that case I can add that the stated reason for this way of doing > things is performance (i.e., emitting data points should not int

Re: [Cake] cake flenter results round 2

@Pete @Toke just saw your responses. Thank you very much for the explanation. I will give irtt and flent-git a try, and maybe build an aur package for archlinux. George On Wed, Nov 29, 2017 at 11:08 AM, Pete Heist wrote: > > > On Nov 29, 2017, at 4:44 PM, Toke Høiland-Jørgensen > wrote: > > >

Re: [Cake] cake flenter results round 2

Georgios Amanakis writes: > @Pete @Toke just saw your responses. Thank you very much for the > explanation. I will give irtt and flent-git a try, and maybe build an > aur package for archlinux. There's already an AUR package for flent-git; haven't gotten around to making one for irtt, but am fin

Re: [Cake] cake flenter results round 2

Pete Heist writes: >> On Nov 29, 2017, at 4:44 PM, Toke Høiland-Jørgensen wrote: >> >>> (That was also informative for me about how netperf decides when to >>> emit a data point…) >> >> In that case I can add that the stated reason for this way of doing >> things is performance (i.e., emitting

Re: [Cake] cake flenter results round 2

I just installed flent-git (thanks for the aur) and irtt, was more straightforward than I expected :) In my setup netserver runs on server, flent runs on client. Where should I run irtt server? George ___ Cake mailing list Cake@lists.bufferbloat.net http

Re: [Cake] cake flenter results round 2

On Wed, Nov 29, 2017 at 5:24 PM Georgios Amanakis wrote: > I just installed flent-git (thanks for the aur) and irtt, was more > straightforward than I expected :) > In my setup netserver runs on server, flent runs on client. Where should I > run irtt server? > irtt server should be run on server

Re: [Cake] cake flenter results round 2

Results with irtt/flent-git. Same setup as before: server -- delay -- mbox -- client netserver 50ms/50ms45/900mbit Cake config: qdisc cake 801b: dev mbox.l root refcnt 2 bandwidth 45Mbit diffserv3 triple-isolate ack-filter-aggressive rtt 100.0ms noat

Re: [Cake] cake flenter results round 2

Georgios Amanakis writes: > Results with irtt/flent-git. Same setup as before: Looks like that is still using netperf for the UDP measurements. Flent does some sanity checks on irtt before using it, which may be failing. Running flent with -v should give some hints... -Toke

[Cake] Fwd: cake flenter results round 2

My fault, I had forgotten to include ~/go/bin in PATH. New files: delay 100ms (rtt) flent: https://drive.google.com/open? id=13HAAvDtkBCPNu5FC61Cge_1vcd5LXuWY delay 100ms (rtt) stat: https://drive.google.com/open?id=1THM- F0MiuCntMz7lx3m7vA1FvHYZSNHC On Wed, Nov 29, 2017 at 11:40 AM, Toke Høila

Re: [Cake] cake flenter results round 2

I just want to verify that you increased the netem limit by a lot in the scripts? tc qdisc add dev whatever root netem delay 10ms limit 10 Georgios Amanakis writes: > I did some more testing. Same setup as before, I varied the amount of delay: > > server -- delay -- mbox -- client > nets

Re: [Cake] cake flenter results round 2

I didn't, it remained at the default value: 1000. I only modified the delay parameter in: "ip netns exec delay tc qdisc replace dev delay.r root netem delay 50ms" On Wed, Nov 29, 2017 at 12:44 PM, Dave Taht wrote: > > I just want to verify that you increased the netem limit by a lot in the > s

[Cake] Fwd: cake flenter results round 2

-- Forwarded message -- From: Georgios Amanakis Date: Wed, Nov 29, 2017 at 12:50 PM Subject: Re: [Cake] cake flenter results round 2 To: Dave Taht To avoid a misunderstanding, the delay parameter in both: "ip netns exec delay tc qdisc replace dev delay.r root netem delay 50ms" "

Re: [Cake] cake flenter results round 2

Also, it is easier (for me at least) to download a tarball of all your results for a given run, rather than each one individually. I am thinking we can rename ack-filter-aggressive to ack-filter-too-damn-aggressive. Dave Taht writes: > I just want to verify that you increased the netem limit b

Re: [Cake] Cake tree unreadable

Sebastian Moeller writes: > Hi All, > > >> On Nov 28, 2017, at 23:37, Dave Taht wrote: >> >> >> A flag day here is feasible. I will fiddle along the lines you describe. >> >> As for other flag days... >> >> I'm toying with the idea of fixing xstats in a separate branch. I really >> hate the

Re: [Cake] Fwd: cake flenter results round 2

Georgios Amanakis writes: > -- Forwarded message -- > From: Georgios Amanakis > Date: Wed, Nov 29, 2017 at 12:50 PM > Subject: Re: [Cake] cake flenter results round 2 > To: Dave Taht > > To avoid a misunderstanding, the delay parameter in both: > "ip netns exec delay tc qdisc re

Re: [Cake] [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek wrote: >> The better solution would of course be to have the TCP peeps change the >> way TCP works so that it sends fewer ACKs. > > Which tends to perturb the way the TCP self-clocking feedback loop works, > and to break Nagle. Linux TCP is no

Re: [Cake] [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 10:28 AM, Juliusz Chroboczek wrote: >> Recently Ryan Mounce added ack filtering cabilities to the cake qdisc. >> The benefits were pretty impressive at a 50x1 Down/Up ratio: > > If I read this posting right, you're only measuring bulk performance. > What about interactive t

Re: [Cake] Fwd: cake flenter results round 2

there is no performance impact of using really high values for netem limit. Stick with 10. :) (well, there is a cache impact, but that's the cost of correct simulation) On Wed, Nov 29, 2017 at 10:19 AM, Georgios Amanakis wrote: > I completely neglected this. It turns out sometimes netem drop

Re: [Cake] 1Gbit/20Mbit D/L with ack-filtering

Very interesting. The aggressive-ack-filter seems to mess throughput up during "boost phase" compared to ack-filter less agreesive. I should say that my most common heavy upload/download usage has an RTT of 88 msec. (Boston - AWS west). Personal heavy upload/download usage is has RTT of abo

Re: [Cake] 1Gbit/20Mbit D/L with ack-filtering

dpr...@reed.com writes: > BTW, one annoying thing about flent is that netperf is not available > in fedora, rhel, centos as a package. So I have to install it and it > doesn't just plug in smoothly. That's just my convenience issue. I > don't use netperf myself on any of my systems. iperf and ipe

[Cake] cake flenter results round 3

http://www.drhleny.cz/bufferbloat/cake/round3/ Round 3 Tarball: http://www.drhleny.cz/bufferbloat/cake/round3.tgz *** Notes/Analysis *** * And another couple hundred tests showing Cake doesn’t

Re: [Cake] cake flenter results round 3

High RTT with relatively high bandwidth is traditionally considered challenging, and is representative of Australasian and satellite connections. Definitely do some of those. Low bandwidth should also be interesting. DSL at 4/1 Mbit is typical entry level package here. - Jonathan Morton ___

Re: [Cake] [Bloat] benefits of ack filtering

On Wed, 29 Nov 2017 10:41:41 -0800 Dave Taht wrote: > On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek wrote: > >> The better solution would of course be to have the TCP peeps change the > >> way TCP works so that it sends fewer ACKs. > > > > Which tends to perturb the way the TCP self-clo

Re: [Cake] [Bloat] benefits of ack filtering

On Wed, 2017-11-29 at 15:59 -0800, Stephen Hemminger wrote: > On Wed, 29 Nov 2017 10:41:41 -0800 > Dave Taht wrote: > > > On Wed, Nov 29, 2017 at 10:21 AM, Juliusz Chroboczek > > wrote: > > > > The better solution would of course be to have the TCP peeps > > > > change the > > > > way TCP works

Re: [Cake] cake flenter results round 3

On Wed, Nov 29, 2017 at 3:18 PM, Pete Heist wrote: > http://www.drhleny.cz/bufferbloat/cake/round3/ > > Round 3 Tarball: http://www.drhleny.cz/bufferbloat/cake/round3.tgz > > *** Notes/Analysis *** > > * And another couple hundred tests showing Cake doesn’t crash, at 20/20mbit > either! > > * I’m

Re: [Cake] [Bloat] benefits of ack filtering

On Wed, Nov 29, 2017 at 10:41:41AM -0800, Dave Taht wrote: > Linux TCP is no longer particularly ack-clocked. In the post pacing, > post sch_fq world, packets are released (currently) on a 1ms schedule. Most Linux hosts don't run sch_fq, though. I mean, it's not even default in a 4.15 kernel. /*