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

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

[Aaron Wood]

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

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.

- 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)

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.

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.

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

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

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

[Dave Taht]

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

[Cerowrt-devel] Definitional Jiu-jitsu (was Re: 3.10.32-12 results on Free.fr)

[Rich Brown]

On Apr 1, 2014, at 2:21 PM, Dave Taht <dave.taht@gmail.com> wrote:

> 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. 

Hmmm... The academic community has finally come to understand the concept, and use the name "bufferbloat". Maybe that's OK, even if their understanding is dramatically different from ours.

Perhaps this is an opportunity to let their momentum fully embrace the Brobdignagian notion that 200 msec is OK, while we pivot agilely to use something like "smarterqueue.net" to define the "real good" scheme? 

I'm not sure we have the gravitas to pull this off, but it's worth considering. 

Rich

PS I can envision the soundtrack in the Youtube video...

... (stirring music) ...
... From the team that conquered Bufferbloat...
... Comes a technique that smashes it by an order of magnitude...
... (trumpets)... 

A fitting idea for a fitting day :-)

Re: [Cerowrt-devel] Definitional Jiu-jitsu (was Re: 3.10.32-12 results on Free.fr)

[Toke Høiland-Jørgensen]

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

Rich Brown <richb.hanover@gmail.com> writes:

> ... (stirring music) ...
> ... From the team that conquered Bufferbloat...
> ... Comes a technique that smashes it by an order of magnitude...
> ... (trumpets)...

I'd watch that! :D

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

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

[Aaron Wood]

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

On Tue, Apr 1, 2014 at 8:21 PM, Dave Taht <dave.taht@gmail.com> wrote:

> 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.


Will do.



> > 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)
>

No I am behind the v6 box.  I keep getting sfq and fq_codel swapped in my
head.


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.
>

Why was the change made to >3.6 fq_codel?


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...
>

Most people don't have uplink >10Mb still, right?  My DOCSIS 3 modem at my
last apartment here in Paris (Numericable) was 30Mb down, 1Mb up.


> 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


That's a pretty substantial difference (at least in how it looks graphed).


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....
>

published papers, at good conferences?  or just "papers".


> 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.netDSL
> > (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.
>

They can do bonded channels, so with two channels bonded with AnnexM, that
could work (if it the range to the CO was still short).  Although I'd be
happy with the download that I have here (16Mb), if I could get 3Mb up with
it using AnnexM.  I probably wouldn't even miss the extra two 2Mb of the
top if download dropped to 14Mb

-Aaron

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