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