From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::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 433BD21F5E4 for ; Sun, 19 Apr 2015 05:11:45 -0700 (PDT) Received: by iebrs15 with SMTP id rs15so99570995ieb.3 for ; Sun, 19 Apr 2015 05:11:45 -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=jKkE/au0snO5YfdcRqnYDQ6esuUHJ3tgli5xjXwVBWc=; b=A5MqVcIGZoCy1RpYLIEEA2NAQhpLlCXP8Gnx4BW/epNcdFAt+YhvTR2ECwddwzohaz NCbc2nXEpr4mI5q5n8cG0CXX9U/tVJCVVPMl+cgMmZYuuTaKf7wxcN4Fa+nCD3C3SNtm nKHQUxrUKK+FHDqmd239bosOBR9ey9l8aMC2q7fYEpABYKfNuXV7g/Gq0yW+g6cYBdAH iHYKr9pEomVOWH9+cSqim2Rh6Bd9iqBwImr/tUCPMHwo3gHBQ/wHADWRnfbLHH7oHny0 Rc0Ie4ESSyc+X00F0kvw1ueuQ4PnE5VJyZWFo6BvK6qmFV650FxYM3PsiIrQcLKzPAR2 dINA== MIME-Version: 1.0 X-Received: by 10.107.9.67 with SMTP id j64mr15803762ioi.39.1429445505199; Sun, 19 Apr 2015 05:11:45 -0700 (PDT) Sender: justinbeech@gmail.com Received: by 10.50.107.42 with HTTP; Sun, 19 Apr 2015 05:11:45 -0700 (PDT) In-Reply-To: References: <1C516386-75C7-4A53-B7E0-7D3A8238C3CE@gmail.com> Date: Sun, 19 Apr 2015 22:11:45 +1000 X-Google-Sender-Auth: Cf-LpbZZHQOhYwssnh6MuhkSq1U Message-ID: From: jb To: bloat Content-Type: multipart/alternative; boundary=001a113df6d69034bb051412b747 Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in 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: Sun, 19 Apr 2015 12:12:14 -0000 --001a113df6d69034bb051412b747 Content-Type: text/plain; charset=UTF-8 Your test used a mixture of Taiwan, Japan and Dallas Texas which were the three best locations. Ideally the test should concentrate less on Dallas/Taiwan, and more on Japan, instead of picking randomly among them. I'll be adjusting the strategy to be more optimal. Then it is just a matter of adding servers. Despite the non optimal choice, as I mentioned, it did test a near gigabit connection at Sony so the servers are not really lacking, just minimising the total of the latency especially for Windows clients. 16.83s stream0 mbits=0.52 (16% of 64k buffer) Dallas, TX, USA 1sec=0.56 5% 16.83s stream1 mbits=0.43 (13% of 64k buffer) Dallas, TX, USA 1sec=0.7 0% 16.83s stream2 mbits=1.94 (61% of 64k buffer) Dallas, TX, USA 1sec=1.62 1% 16.83s stream3 mbits=7.3 (39% of 64k buffer) Tokyo, Japan 1sec=8.77 3% 16.83s stream4 mbits=3.46 (35% of 64k buffer) Changhua, Taiwan 1sec=5.23 2% 16.83s stream5 mbits=1.36 (43% of 64k buffer) Dallas, TX, USA 1sec=1.85 1% 16.83s stream6 mbits=0.78 (24% of 64k buffer) Dallas, TX, USA 1sec=1.39 0% 16.83s stream7 mbits=1.62 (51% of 64k buffer) Dallas, TX, USA 1sec=0.83 1% 16.83s stream8 mbits=0.67 (21% of 64k buffer) Dallas, TX, USA 1sec=0.65 0% 16.83s stream9 mbits=8.64 (46% of 64k buffer) Tokyo, Japan 1sec=6.82 3% 16.83s stream10 mbits=3.81 (38% of 64k buffer) Changhua, Taiwan 1sec=3.11 2% 16.83s stream11 mbits=0.27 (8% of 64k buffer) Dallas, TX, USA 1sec=0.6 0% 16.83s stream12 mbits=1.67 (17% of 64k buffer) Changhua, Taiwan 1sec=3.24 1% 16.83s stream13 mbits=5.83 (31% of 64k buffer) Tokyo, Japan 1sec=6.04 3% 16.83s stream14 mbits=3.17 (32% of 64k buffer) Changhua, Taiwan 1sec=3.42 1% 16.83s stream15 mbits=3.46 (35% of 64k buffer) Changhua, Taiwan 1sec=2.75 2% 16.83s stream16 mbits=1.19 (37% of 64k buffer) Dallas, TX, USA 1sec=0.72 0% 16.83s stream17 mbits=6.07 (32% of 64k buffer) Tokyo, Japan 1sec=13.31 2% 16.83s stream18 mbits=0.8 (25% of 64k buffer) Dallas, TX, USA 1sec=1.39 0% 16.83s stream19 mbits=1.44 (45% of 64k buffer) Dallas, TX, USA 1sec=0.65 1% 16.83s stream20 mbits=4.11 (42% of 64k buffer) Changhua, Taiwan 1sec=2.37 2% 16.83s stream21 mbits=1.25 (39% of 64k buffer) Dallas, TX, USA 1sec=0.67 1% 16.83s stream22 mbits=6.13 (33% of 64k buffer) Tokyo, Japan 1sec=6.75 3% 16.83s stream23 mbits=4.12 (22% of 64k buffer) Tokyo, Japan 1sec=6.04 2% On Sun, Apr 19, 2015 at 8:53 PM, dikshie wrote: > On Sun, Apr 19, 2015 at 9:57 AM, Rich Brown > wrote: > > Folks, > > > > I am delighted to pass along the news that Justin has added latency > measurements into the Speed Test at DSLReports.com. > > > > Go to: https://www.dslreports.com/speedtest and click the button for > your Internet link. This controls the number of simultaneous connections > that get established between your browser and the speedtest server. After > you run the test, click the green "Results + Share" button to see detailed > info. For the moment, you need to be logged in to see the latency results. > There's a "register" link on each page. > > > > The speed test measures latency using websocket pings: Justin says that > a zero-latency link can give 1000 Hz - faster than a full HTTP ping. I just > ran a test and got 48 msec latency from DSLReports, while ping gstatic.com > gave 38-40 msec, so they're pretty fast. > > > > You can leave feedback on this page - > http://www.dslreports.com/forum/r29910594-FYI-for-general-feedback-on-the-new-speedtest > - or wait 'til Justin creates a new Bufferbloat topic on the forums. > > > > here from JP: > http://www.dslreports.com/speedtest/320711 > > there are not many servers in JP. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --001a113df6d69034bb051412b747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Your test used a mixture of Taiwan, Japan and Dallas Texas= which were the three best locations.
Ideally the test should conc= entrate less on Dallas/Taiwan, and more on Japan, instead of picking random= ly among them.

I'll be adjusting the strategy = to be more optimal. Then it is just a matter of adding servers.
<= br>
Despite the non optimal choice, as I mentioned, it did test a= near gigabit connection at Sony so the servers are not really lacking, jus= t minimising the total of the latency especially for Windows clients.
=

16.83s =C2=A0stream0 mbits=3D0.52 (16% of 64k= buffer) Dallas, TX, USA 1sec=3D0.56 5%
16.83s =C2=A0stream1 mbit= s=3D0.43 (13% of 64k buffer) Dallas, TX, USA 1sec=3D0.7 0%
16.83s= =C2=A0stream2 mbits=3D1.94 (61% of 64k buffer) Dallas, TX, USA 1sec=3D1.62= 1%
16.83s =C2=A0stream3 mbits=3D7.3 (39% of 64k buffer) Tokyo, J= apan 1sec=3D8.77 3%
16.83s =C2=A0stream4 mbits=3D3.46 (35% of 64k= buffer) Changhua, Taiwan 1sec=3D5.23 2%
16.83s =C2=A0stream5 mbi= ts=3D1.36 (43% of 64k buffer) Dallas, TX, USA 1sec=3D1.85 1%
16.8= 3s =C2=A0stream6 mbits=3D0.78 (24% of 64k buffer) Dallas, TX, USA 1sec=3D1.= 39 0%
16.83s =C2=A0stream7 mbits=3D1.62 (51% of 64k buffer) Dalla= s, TX, USA 1sec=3D0.83 1%
16.83s =C2=A0stream8 mbits=3D0.67 (21% = of 64k buffer) Dallas, TX, USA 1sec=3D0.65 0%
16.83s =C2=A0stream= 9 mbits=3D8.64 (46% of 64k buffer) Tokyo, Japan 1sec=3D6.82 3%
16= .83s =C2=A0stream10 mbits=3D3.81 (38% of 64k buffer) Changhua, Taiwan 1sec= =3D3.11 2%
16.83s =C2=A0stream11 mbits=3D0.27 (8% of 64k buffer) = Dallas, TX, USA 1sec=3D0.6 0%
16.83s =C2=A0stream12 mbits=3D1.67 = (17% of 64k buffer) Changhua, Taiwan 1sec=3D3.24 1%
16.83s =C2=A0= stream13 mbits=3D5.83 (31% of 64k buffer) Tokyo, Japan 1sec=3D6.04 3%
=
16.83s =C2=A0stream14 mbits=3D3.17 (32% of 64k buffer) Changhua, Taiwa= n 1sec=3D3.42 1%
16.83s =C2=A0stream15 mbits=3D3.46 (35% of 64k b= uffer) Changhua, Taiwan 1sec=3D2.75 2%
16.83s =C2=A0stream16 mbit= s=3D1.19 (37% of 64k buffer) Dallas, TX, USA 1sec=3D0.72 0%
16.83= s =C2=A0stream17 mbits=3D6.07 (32% of 64k buffer) Tokyo, Japan 1sec=3D13.31= 2%
16.83s =C2=A0stream18 mbits=3D0.8 (25% of 64k buffer) Dallas,= TX, USA 1sec=3D1.39 0%
16.83s =C2=A0stream19 mbits=3D1.44 (45% o= f 64k buffer) Dallas, TX, USA 1sec=3D0.65 1%
16.83s =C2=A0stream2= 0 mbits=3D4.11 (42% of 64k buffer) Changhua, Taiwan 1sec=3D2.37 2%
16.83s =C2=A0stream21 mbits=3D1.25 (39% of 64k buffer) Dallas, TX, USA 1s= ec=3D0.67 1%
16.83s =C2=A0stream22 mbits=3D6.13 (33% of 64k buffe= r) Tokyo, Japan 1sec=3D6.75 3%
16.83s =C2=A0stream23 mbits=3D4.12= (22% of 64k buffer) Tokyo, Japan 1sec=3D6.04 2%

=


On Sun, Apr 19, 2015 at 8:53 PM, dikshie <dikshie@gmail.c= om> wrote:
On Sun, Apr 19, 2015 at 9:57 AM, Rich Brown <richb.hanover@gmail.com> wro= te:
> Folks,
>
> I am delighted to pass along the news that Justin has added latency me= asurements into the Speed Test at DSLReports.com.
>
> Go to: https://www.dslreports.com/speedtest and click the button for your = Internet link. This controls the number of simultaneous connections that ge= t established between your browser and the speedtest server. After you run = the test, click the green "Results + Share" button to see detaile= d info. For the moment, you need to be logged in to see the latency results= . There's a "register" link on each page.
>
> The speed test measures latency using websocket pings: Justin says tha= t a zero-latency link can give 1000 Hz - faster than a full HTTP ping. I ju= st ran a test and got 48 msec latency from DSLReports, while ping gstatic.com gave 38-40 msec, = so they're pretty fast.
>
> You can leave feedback on this page - http://www.dslreports.com/forum/r29910594-FYI-for-general-feedb= ack-on-the-new-speedtest - or wait 'til Justin creates a new Buffer= bloat topic on the forums.



here from JP:
ht= tp://www.dslreports.com/speedtest/320711

there are not many servers in JP.
___________________________________= ____________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat

--001a113df6d69034bb051412b747--