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 <dikshie@gmail.com> wrote:
On Sun, Apr 19, 2015 at 9:57 AM, Rich Brown <richb.hanover@gmail.com> 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