<div dir="ltr">The display of the latency during the test are purely from the<div>view of the browser doing what should be instant web socket pings.</div><div><br></div><div>Now if you guys tell me that by inspection of the traffic the browser</div><div>has no excuse, it should not be getting its pings back late, and/or you</div><div>just run an icmp ping to <a href="http://dslreports.com">dslreports.com</a> during the download phase and</div><div>it also shows that there is no delay, then I would not be surprised.</div><div><br></div><div>(although the reported delays during upload that I see at least are</div><div>completely real because I am typing over SSH when the delays spike</div><div>and it is 1:1).</div><div><br></div><div>So anyway if you have reason to believe the browser is getting into</div><div>trouble juggling its web socket and the downloads at the same time,</div><div>I will change the test to run the web socket ping in a web worker.</div><div><br></div><div>A web worker is another complete interpreter, with its own thread</div><div>and is supposed to be able to do work in parallel with the main</div><div>page of scripts. Although who knows what happens lower down</div><div>the stack. I'm happy to try this, if there is a suspicious that the main</div><div>ping must be getting perturbed by handling the downloads.</div><div><br></div><div>Also to those using Firefox on Linux, there is strong evidence that </div><div>the noscript extension is causing massive performance problems on</div><div>that combination of OS+Browser.</div><div><br></div><div>Basically 50% of Firefox on Linux tests get constant stalling but no</div><div>Chrome on Linux tests do. 50% might be the population of users</div><div>who use noscript with Linux, it is a popular extension. At least</div><div>one user makes all their performance issues go away be disabling</div><div>noscript and they all come back by re-enabling noscript so I definitely</div><div>want to dig into this more.</div><div><br></div><div>thanks</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 28, 2015 at 8:56 AM, Dave Taht <span dir="ltr"><<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">monitoring queue depth at the minimum interval (100ms) I can do<br>
without writing special tools, I do not see delays greater than 60ms<br>
at the inbound qdisc, nor excessive numbers of packets outstanding.<br>
<br>
watch -n .1 tc -s qdisc show dev ifb4eth2<br>
<br>
Yet this is reporting inbound delays in excess of 4 sec, and pauses:<br>
<br>
<a href="http://www.dslreports.com/speedtest/378332" target="_blank">http://www.dslreports.com/speedtest/378332</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Apr 27, 2015 at 2:28 PM, Dave Taht <<a href="mailto:dave.taht@gmail.com">dave.taht@gmail.com</a>> wrote:<br>
> For reference, this is the comcast link under test, with no shaping at all:<br>
><br>
> <a href="http://www.dslreports.com/speedtest/377563" target="_blank">http://www.dslreports.com/speedtest/377563</a><br>
><br>
> (horrific, isn't it?)<br>
><br>
> I did a few fq_codel + ecn tests<br>
><br>
> <a href="http://www.dslreports.com/speedtest/377389" target="_blank">http://www.dslreports.com/speedtest/377389</a><br>
> <a href="http://www.dslreports.com/speedtest/377429" target="_blank">http://www.dslreports.com/speedtest/377429</a><br>
><br>
> And cake: <a href="http://www.dslreports.com/speedtest/377505" target="_blank">http://www.dslreports.com/speedtest/377505</a><br>
><br>
> No ecn fq_codel: <a href="http://www.dslreports.com/speedtest/377443" target="_blank">http://www.dslreports.com/speedtest/377443</a><br>
><br>
> no ecn with pie: <a href="http://www.dslreports.com/speedtest/377488" target="_blank">http://www.dslreports.com/speedtest/377488</a><br>
><br>
> no ecn with ns2_codel: <a href="http://www.dslreports.com/speedtest/377563" target="_blank">http://www.dslreports.com/speedtest/377563</a><br>
><br>
> no ecn with codel: <a href="http://www.dslreports.com/speedtest/377703" target="_blank">http://www.dslreports.com/speedtest/377703</a><br>
><br>
> It is difficult to conclude anything from the download tests without<br>
> 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 would<br>
> assume it was the browser misbehaving on downloads, or the server. The<br>
> tcp_download tests taken with the same setup with netperf-wrapper show<br>
> what I had assumed til now a normal variance of latency.<br>
><br>
> <a href="http://snapon.lab.bufferbloat.net/~d/yurtlab100.tgz" target="_blank">http://snapon.lab.bufferbloat.net/~d/yurtlab100.tgz</a> is that set of results<br>
><br>
> <a href="http://snapon.lab.bufferbloat.net/~d/yurtlab100/tcp_download_vs_dslreports.png" target="_blank">http://snapon.lab.bufferbloat.net/~d/yurtlab100/tcp_download_vs_dslreports.png</a><br>
><br>
> Puzzled, I<br>
><br>
> repeated  the pie with no ecn test:<br>
><br>
> <a href="http://www.dslreports.com/speedtest/377727" target="_blank">http://www.dslreports.com/speedtest/377727</a><br>
><br>
> turned off ecn for a fq_codel test on the tcp itself:<br>
><br>
> <a href="http://www.dslreports.com/speedtest/377765" target="_blank">http://www.dslreports.com/speedtest/377765</a><br>
><br>
> and for this fq_codel test, dropped the inbound shaper from 115 mbit<br>
> down to 110, which did improve matters somewhat.<br>
><br>
> <a href="http://www.dslreports.com/speedtest/377786" target="_blank">http://www.dslreports.com/speedtest/377786</a><br>
><br>
><br>
> [1] both ns2_codel and cake are experimental<br>
> --<br>
> Dave Täht<br>
> Open Networking needs **Open Source Hardware**<br>
><br>
> <a href="https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67" target="_blank">https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67</a><br>
<br>
<br>
<br>
--<br>
Dave Täht<br>
Open Networking needs **Open Source Hardware**<br>
<br>
<a href="https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67" target="_blank">https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67</a><br>
</div></div></blockquote></div><br></div>