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

[Aaron Wood]

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

> On Thu, Mar 27, 2014 at 3:21 AM, Aaron Wood <woody77 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20140402/07f319e8/attachment-0002.html>