Re: [Cerowrt-devel] 3.10.32-12 results on Free.fr

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

On Thu, Mar 27, 2014 at 3:21 AM, Aaron Wood <woody77@gmail.com> wrote:
> Dave had asked about results from .32-12 on DSL, and in particular how pie
> was fairing on dsl.  I finally was able to setup a clean test env yesterday,
> and ran a bunch of tests.
>
> Results:
> http://burntchrome.blogspot.com/2014/03/cerowrt-31032-12-sqm-comparison-on.html
>
> Takeaways:
>
> - I'm still dropping a lot of "small-flow" packets when heavily loaded, I'm
> not sure why.  Free.fr's freebox doesn't do this, it's definitely in cero.

Try the simplest.qos model.

>
> - pie still sucks on dsl (or on my dsl).  latency with rrul was up over 1sec
> (and continually growing over the course of the test)

Hmm. I see it spike at 120ms on the rrul test and also otherwise
have trouble with stuff in slow start, particularly at bandwidths below 5mbit...

>
> I feel like _something_ is misconfigured, and that's why I'm dropping
> packets the way that I am.  I really would like to solve that.  Free.fr's
> sfq implementation behaves quite nicely, and by comparison, doesn't drop UDP
> packets under load.

So you are not behind a freedombox revolution V6?  (that's the linux
3.6 fq_codel version)

post 3.6 fq_codel will drop some packets from all flows in order to reduce
latency. I wish the netperf benchmark had better behavior for the udp
flows rather than stopping after the first loss... some non-bursty
packet loss really isn't a problem for things like voip, and dns
traffic. But that said, I liked this 3.6 behavior of codel and
sometimes wish we had a better solution for sparser flows under heavy
load than what is in there now.

Pie has sprouted a very large estimation window in the Linux release,
and it's not a surprise to me that it doesn't work well below 10Mbit...

But I have generally been reluctant to publish benchmarks on pie of my own
(since, despite working on making pie work rather hard, I would be
seen to have a bias), and thus I encourage others to try it using
whatever benchmarks they wish to use, and keep working on finding ways
to improve the ns2 models others are working from...

Now that there is a final pie version in linux 3.14, I feel more
comfortable attempting benchmarks on a wide range of bandwidths and
conditions, (but would prefer more people tried more stuff). I DID do
some testing with webrtc today, and am thinking leveraging/improving
their benchmarks and methods with testing aqm and packet schedulers
makes sense.

A 3 way intercontinental call was pretty much perfect with fq_codel
while running a rrul test:

http://snapon.lab.bufferbloat.net/~d/mike/webrtc.svg

(the dip in the data was when I ALSO transferred a large file)

And the pie result, while not horrible, did have some sort of observable
problems when I hit it with traffic in slow start, which I didn't
manage to capture...

http://snapon.lab.bufferbloat.net/~d/mike/pie.svg

One thing I've noticed is the academic community is now seemingly defining
"bufferbloat" as something that happens with > 200ms induced queuing
delay delay, where I (we) define it as "excessive queueing", and in
this group, are "settling" for <20ms delay in both directions in most
cases. This really changes the mental model a lot. TCP reacts very
differently at 200ms RTT than 5ms.

I keep seeing papers that put one end of the link with 100ms worth of buffering,
against X aqm on the other end of the link, and doing measurements...
where here we artificially put it on both sides lacking hope the big
dlsm/cmts vendors will do anything to fix it....

The part that bugs me is that if you say "bufferbloat is > 200ms
induced queuing delay" and then look at data, you can show that
bufferbloat occurs only rarely in the 90 percentile of normal use.

If on the other hand you regard > 20ms queuing delay as  bufferbloat,
or something more dynamic like "persistent queue lasting more than X *
1.1 * RTT", the rate of bufferbloat occurrence in the real world goes
way, way, up.


>
> This was all ipv4-only (I haven't asked the apartment owner to turn on ipv6
> with Free.fr).
>
> In about 2 months, I'll be back in the Bay Area.  With either sonic.net DSL
> (bonded channels for 30/2 service), or with Comcast.  Comcast most likely.
> It would be nice to have 3-5Mb upload again.

sonic has a higher end service too, so far as I know.

> Any other tests/questions, feel free to ask.  I can perform tests in the
> morning and early afternoon when things are quiet around here.
>
> -Aaron
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html