[Bloat] some 110Mbit cable testing of the new dslreports stuff

[Bloat] some 110Mbit cable testing of the new dslreports stuff

[Dave Taht]

For reference, this is the comcast link under test, with no shaping at all:

http://www.dslreports.com/speedtest/377563

(horrific, isn't it?)

I did a few fq_codel + ecn tests

http://www.dslreports.com/speedtest/377389
http://www.dslreports.com/speedtest/377429

And cake: http://www.dslreports.com/speedtest/377505

No ecn fq_codel: http://www.dslreports.com/speedtest/377443

no ecn with pie: http://www.dslreports.com/speedtest/377488

no ecn with ns2_codel: http://www.dslreports.com/speedtest/377563

no ecn with codel: http://www.dslreports.com/speedtest/377703

It is difficult to conclude anything from the download tests without
going through the captures, although the uplink tests look reasonable
compared to the rrul tests. If it wasn't for the pie result, I would
assume it was the browser misbehaving on downloads, or the server. The
tcp_download tests taken with the same setup with netperf-wrapper show
what I had assumed til now a normal variance of latency.

http://snapon.lab.bufferbloat.net/~d/yurtlab100.tgz is that set of results

http://snapon.lab.bufferbloat.net/~d/yurtlab100/tcp_download_vs_dslreports.png

Puzzled, I

repeated  the pie with no ecn test:

http://www.dslreports.com/speedtest/377727

turned off ecn for a fq_codel test on the tcp itself:

http://www.dslreports.com/speedtest/377765

and for this fq_codel test, dropped the inbound shaper from 115 mbit
down to 110, which did improve matters somewhat.

http://www.dslreports.com/speedtest/377786


[1] both ns2_codel and cake are experimental
-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff

[Dave Taht]

monitoring queue depth at the minimum interval (100ms) I can do
without writing special tools, I do not see delays greater than 60ms
at the inbound qdisc, nor excessive numbers of packets outstanding.

watch -n .1 tc -s qdisc show dev ifb4eth2

Yet this is reporting inbound delays in excess of 4 sec, and pauses:

http://www.dslreports.com/speedtest/378332


On Mon, Apr 27, 2015 at 2:28 PM, Dave Taht <dave.taht@gmail.com> wrote:
> For reference, this is the comcast link under test, with no shaping at all:
>
> http://www.dslreports.com/speedtest/377563
>
> (horrific, isn't it?)
>
> I did a few fq_codel + ecn tests
>
> http://www.dslreports.com/speedtest/377389
> http://www.dslreports.com/speedtest/377429
>
> And cake: http://www.dslreports.com/speedtest/377505
>
> No ecn fq_codel: http://www.dslreports.com/speedtest/377443
>
> no ecn with pie: http://www.dslreports.com/speedtest/377488
>
> no ecn with ns2_codel: http://www.dslreports.com/speedtest/377563
>
> no ecn with codel: http://www.dslreports.com/speedtest/377703
>
> It is difficult to conclude anything from the download tests without
> going through the captures, although the uplink tests look reasonable
> compared to the rrul tests. If it wasn't for the pie result, I would
> assume it was the browser misbehaving on downloads, or the server. The
> tcp_download tests taken with the same setup with netperf-wrapper show
> what I had assumed til now a normal variance of latency.
>
> http://snapon.lab.bufferbloat.net/~d/yurtlab100.tgz is that set of results
>
> http://snapon.lab.bufferbloat.net/~d/yurtlab100/tcp_download_vs_dslreports.png
>
> Puzzled, I
>
> repeated  the pie with no ecn test:
>
> http://www.dslreports.com/speedtest/377727
>
> turned off ecn for a fq_codel test on the tcp itself:
>
> http://www.dslreports.com/speedtest/377765
>
> and for this fq_codel test, dropped the inbound shaper from 115 mbit
> down to 110, which did improve matters somewhat.
>
> http://www.dslreports.com/speedtest/377786
>
>
> [1] both ns2_codel and cake are experimental
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67

Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff

[Jonathan Morton]

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

Well, shaping downstream of the true bottleneck is somewhat less effective
than shaping upstream of it. Transiently, some of the queue is in the link
FIFO rather than in the managed queue.

- Jonathan Morton

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

Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff

[jb]

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

The display of the latency during the test are purely from the
view of the browser doing what should be instant web socket pings.

Now if you guys tell me that by inspection of the traffic the browser
has no excuse, it should not be getting its pings back late, and/or you
just run an icmp ping to dslreports.com during the download phase and
it also shows that there is no delay, then I would not be surprised.

(although the reported delays during upload that I see at least are
completely real because I am typing over SSH when the delays spike
and it is 1:1).

So anyway if you have reason to believe the browser is getting into
trouble juggling its web socket and the downloads at the same time,
I will change the test to run the web socket ping in a web worker.

A web worker is another complete interpreter, with its own thread
and is supposed to be able to do work in parallel with the main
page of scripts. Although who knows what happens lower down
the stack. I'm happy to try this, if there is a suspicious that the main
ping must be getting perturbed by handling the downloads.

Also to those using Firefox on Linux, there is strong evidence that
the noscript extension is causing massive performance problems on
that combination of OS+Browser.

Basically 50% of Firefox on Linux tests get constant stalling but no
Chrome on Linux tests do. 50% might be the population of users
who use noscript with Linux, it is a popular extension. At least
one user makes all their performance issues go away be disabling
noscript and they all come back by re-enabling noscript so I definitely
want to dig into this more.

thanks


On Tue, Apr 28, 2015 at 8:56 AM, Dave Taht <dave.taht@gmail.com> wrote:

> monitoring queue depth at the minimum interval (100ms) I can do
> without writing special tools, I do not see delays greater than 60ms
> at the inbound qdisc, nor excessive numbers of packets outstanding.
>
> watch -n .1 tc -s qdisc show dev ifb4eth2
>
> Yet this is reporting inbound delays in excess of 4 sec, and pauses:
>
> http://www.dslreports.com/speedtest/378332
>
>
> On Mon, Apr 27, 2015 at 2:28 PM, Dave Taht <dave.taht@gmail.com> wrote:
> > For reference, this is the comcast link under test, with no shaping at
> all:
> >
> > http://www.dslreports.com/speedtest/377563
> >
> > (horrific, isn't it?)
> >
> > I did a few fq_codel + ecn tests
> >
> > http://www.dslreports.com/speedtest/377389
> > http://www.dslreports.com/speedtest/377429
> >
> > And cake: http://www.dslreports.com/speedtest/377505
> >
> > No ecn fq_codel: http://www.dslreports.com/speedtest/377443
> >
> > no ecn with pie: http://www.dslreports.com/speedtest/377488
> >
> > no ecn with ns2_codel: http://www.dslreports.com/speedtest/377563
> >
> > no ecn with codel: http://www.dslreports.com/speedtest/377703
> >
> > It is difficult to conclude anything from the download tests without
> > going through the captures, although the uplink tests look reasonable
> > compared to the rrul tests. If it wasn't for the pie result, I would
> > assume it was the browser misbehaving on downloads, or the server. The
> > tcp_download tests taken with the same setup with netperf-wrapper show
> > what I had assumed til now a normal variance of latency.
> >
> > http://snapon.lab.bufferbloat.net/~d/yurtlab100.tgz is that set of
> results
> >
> >
> http://snapon.lab.bufferbloat.net/~d/yurtlab100/tcp_download_vs_dslreports.png
> >
> > Puzzled, I
> >
> > repeated  the pie with no ecn test:
> >
> > http://www.dslreports.com/speedtest/377727
> >
> > turned off ecn for a fq_codel test on the tcp itself:
> >
> > http://www.dslreports.com/speedtest/377765
> >
> > and for this fq_codel test, dropped the inbound shaper from 115 mbit
> > down to 110, which did improve matters somewhat.
> >
> > http://www.dslreports.com/speedtest/377786
> >
> >
> > [1] both ns2_codel and cake are experimental
> > --
> > Dave Täht
> > Open Networking needs **Open Source Hardware**
> >
> > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>
>
>
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67
>

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

Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff

[Dave Taht]

revisiting the ratings on these tests below, the first test should get
an F, somehow. That is *normal* behavior for a comcast link.

The rest look pretty good, fq_codel generally gets an A, pure AQM a B.

On Mon, Apr 27, 2015 at 2:28 PM, Dave Taht <dave.taht@gmail.com> wrote:
> For reference, this is the comcast link under test, with no shaping at all:
>
> http://www.dslreports.com/speedtest/377563
>
> (horrific, isn't it?)
>
> I did a few fq_codel + ecn tests
>
> http://www.dslreports.com/speedtest/377389
> http://www.dslreports.com/speedtest/377429
>
> And cake: http://www.dslreports.com/speedtest/377505
>
> No ecn fq_codel: http://www.dslreports.com/speedtest/377443
>
> no ecn with pie: http://www.dslreports.com/speedtest/377488
>
> no ecn with ns2_codel: http://www.dslreports.com/speedtest/377563
>
> no ecn with codel: http://www.dslreports.com/speedtest/377703
>
> It is difficult to conclude anything from the download tests without
> going through the captures, although the uplink tests look reasonable
> compared to the rrul tests. If it wasn't for the pie result, I would
> assume it was the browser misbehaving on downloads, or the server. The
> tcp_download tests taken with the same setup with netperf-wrapper show
> what I had assumed til now a normal variance of latency.
>
> http://snapon.lab.bufferbloat.net/~d/yurtlab100.tgz is that set of results
>
> http://snapon.lab.bufferbloat.net/~d/yurtlab100/tcp_download_vs_dslreports.png
>
> Puzzled, I
>
> repeated  the pie with no ecn test:
>
> http://www.dslreports.com/speedtest/377727
>
> turned off ecn for a fq_codel test on the tcp itself:
>
> http://www.dslreports.com/speedtest/377765
>
> and for this fq_codel test, dropped the inbound shaper from 115 mbit
> down to 110, which did improve matters somewhat.
>
> http://www.dslreports.com/speedtest/377786
>
>
> [1] both ns2_codel and cake are experimental
> --
> Dave Täht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67



-- 
Dave Täht
Open Networking needs **Open Source Hardware**

https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67