From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2804921F1FB for ; Mon, 27 Apr 2015 23:59:28 -0700 (PDT) Received: by iget9 with SMTP id t9so83057805ige.1 for ; Mon, 27 Apr 2015 23:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=DmzhUnyP5G8IQV3EwsoaYHsTmlIXCdTdh6gRDqiTuPU=; b=Yx91jsCUOsoOLN46ec2GUk0ObPtCBmZGEY3eFgosvscN2kzd0/eUYYnH1Urb4fdX9Y aFCns+6lsrIW4hwgzSUNT54tjNJ771j1zZo3f/pwPcOu1FGB2dbNw70qBHCS1VRy/nFS /TkFLXLzdJtcbBNlOc0efrL044C1kme2rESQq/v3+0AIDmuBTJC4ohxIRycKZqu0E9vZ bChNdzieZcr0fOx1/Yfumsd56RlAH4aoJcSdF58oCNKUY6JhfN0WQvaxmxJKroXfkw1A fnG/x4uhToeAAB5/SpQPgDQuF3hXW0HGoBNbS6JGJbVWO9I6qX0FWOfNQH9IQlwltTIi 2HXA== MIME-Version: 1.0 X-Received: by 10.43.63.76 with SMTP id xd12mr16916634icb.11.1430204367810; Mon, 27 Apr 2015 23:59:27 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Mon, 27 Apr 2015 23:59:27 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Apr 2015 16:59:27 +1000 X-Google-Sender-Auth: jhRB-tIWIE6wYA8_SxsAfH9QHpU Message-ID: From: jb To: Dave Taht , bloat Content-Type: multipart/alternative; boundary=bcaec51a8a964cb5960514c367de Subject: Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 06:59:57 -0000 --bcaec51a8a964cb5960514c367de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 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_dslreport= s.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=C3=A4ht > > Open Networking needs **Open Source Hardware** > > > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > > > > -- > Dave T=C3=A4ht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > --bcaec51a8a964cb5960514c367de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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.<= /div>

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

So a= nyway if you have reason to believe the browser is getting into
t= rouble 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.
<= div>
A web worker is another complete interpreter, with its o= wn thread
and is supposed to be able to do work in parallel with = the main
page of scripts. Although who knows what happens lower d= own
the stack. I'm happy to try this, if there is a suspiciou= s that the main
ping must be getting perturbed by handling the do= wnloads.

Also to those using Firefox on Linux, the= re is strong evidence that=C2=A0
the noscript extension is causin= g massive performance problems on
that combination of OS+Browser.=

Basically 50% of Firefox on Linux tests get const= ant stalling but no
Chrome on Linux tests do. 50% might be the po= pulation of users
who use noscript with Linux, it is a popular ex= tension. 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:
ht= tp://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<= br> > compared to the rrul tests. If it wasn't for the pie result, I wou= ld
> 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=C2=A0 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=C3=A4ht
> Open Networking needs **Open Source Hardware**
>
> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr= 67



--
Dave T=C3=A4ht
Open Networking needs **Open Source Hardware**

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

--bcaec51a8a964cb5960514c367de--