* [Bloat] some 110Mbit cable testing of the new dslreports stuff @ 2015-04-27 21:28 Dave Taht 2015-04-27 22:56 ` Dave Taht ` (2 more replies) 0 siblings, 3 replies; 5+ messages in thread From: Dave Taht @ 2015-04-27 21:28 UTC (permalink / raw) To: bloat, Justin Beech 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff 2015-04-27 21:28 [Bloat] some 110Mbit cable testing of the new dslreports stuff Dave Taht @ 2015-04-27 22:56 ` Dave Taht 2015-04-28 6:59 ` jb 2015-04-27 22:58 ` Jonathan Morton 2015-04-30 4:47 ` Dave Taht 2 siblings, 1 reply; 5+ messages in thread From: Dave Taht @ 2015-04-27 22:56 UTC (permalink / raw) To: bloat, Justin Beech 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff 2015-04-27 22:56 ` Dave Taht @ 2015-04-28 6:59 ` jb 0 siblings, 0 replies; 5+ messages in thread From: jb @ 2015-04-28 6:59 UTC (permalink / raw) To: Dave Taht, bloat [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff 2015-04-27 21:28 [Bloat] some 110Mbit cable testing of the new dslreports stuff Dave Taht 2015-04-27 22:56 ` Dave Taht @ 2015-04-27 22:58 ` Jonathan Morton 2015-04-30 4:47 ` Dave Taht 2 siblings, 0 replies; 5+ messages in thread From: Jonathan Morton @ 2015-04-27 22:58 UTC (permalink / raw) To: Dave Taht; +Cc: bloat [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bloat] some 110Mbit cable testing of the new dslreports stuff 2015-04-27 21:28 [Bloat] some 110Mbit cable testing of the new dslreports stuff Dave Taht 2015-04-27 22:56 ` Dave Taht 2015-04-27 22:58 ` Jonathan Morton @ 2015-04-30 4:47 ` Dave Taht 2 siblings, 0 replies; 5+ messages in thread From: Dave Taht @ 2015-04-30 4:47 UTC (permalink / raw) To: bloat, Justin Beech 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-04-30 4:47 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-27 21:28 [Bloat] some 110Mbit cable testing of the new dslreports stuff Dave Taht 2015-04-27 22:56 ` Dave Taht 2015-04-28 6:59 ` jb 2015-04-27 22:58 ` Jonathan Morton 2015-04-30 4:47 ` Dave Taht
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox