タイトルの通りです。
私の環境だけの可能性もありますが、FirefoxQuantumでβ版JavaScriptで測定を行った場合、
測定中RTT(特に最大値)が300～600msと極めて高く出ます。
そこで、Edgeで試したところ6～8msの範囲に収まりました。
これらの結果は何度測定しても共に変わりませんでした。
Firefox Quantum 64bit 61.0.4
Microsoft Edge バージョン不明(Windows10最新状態)

=== Radish Network Speed Testing Ver.5.3.3.0 β - Test Report ===
使用回線: So-net NURO 光
プロバイダ: So-net
-----------------------------------------------------------------
測定条件
 精度: 高 接続数: 1-16 RTT測定: 速度測定前後/速度測定中
 データタイプ: 標準 測定クライアント: JavaScript
下り回線
 速度: 395.6Mbps (49.46MByte/sec) 測定品質: 88.8 接続数: 4
 測定前RTT: 4.51ms (3.88ms - 5.74ms)
 測定中RTT: 18.4ms (5.46ms - 68.6ms)
上り回線
 速度: 695.0Mbps (86.88MByte/sec) 測定品質: 91.2 接続数: 4
 測定前RTT: 3.33ms (3.00ms - 4.01ms)
 測定中RTT: 5.08ms (2.00ms - 24.0ms)
測定者ホスト: **********.chbd***.ap.nuro.jp
測定時刻: 2018/7/7 09:18:06
-----------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/

ブラウザ Firefox 61.01 64bit
自分の環境では問題ないですね。

=== Radish Network Speed Testing Ver.5.3.3.0 β - Test Report ===
測定条件
 精度: 高 接続数: 1-16 RTT測定: 速度測定前後/速度測定中
 データタイプ: 圧縮可能性低 測定クライアント: JavaScript
下り回線
 速度: 352.6Mbps (44.08MByte/sec) 測定品質: 91.5 接続数: 8
 測定前RTT: 12.7ms (12.1ms - 13.5ms)
 測定中RTT: 24.4ms (11.9ms - 54.1ms)
上り回線
 速度: 581.6Mbps (72.70MByte/sec) 測定品質: 97.5 接続数: 16
 測定前RTT: 12.7ms (12.0ms - 13.0ms)
 測定中RTT: 20.6ms (14.0ms - 24.0ms)
測定者ホスト: ab136113.dynamic.ppp.asahi-net.or.jp
測定時刻: 2018/7/9 20:52:02
-----------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/
=================================================================

【14643】さんでした。

=== Radish Network Speed Testing Ver.5.3.3.0 β - Test Report ===
使用回線: NTT東 Bフレッツ マンションタイプ VDSL方式
プロバイダ: So-net
測定地: 長野県松本市
-----------------------------------------------------------------
測定条件
 精度: 高 接続数: 1-16 RTT測定: 速度測定前後/速度測定中
 データタイプ: 標準 測定クライアント: JavaScript
下り回線
 速度: 15.95Mbps (1.994MByte/sec) 測定品質: 74.5 接続数: 2
 測定前RTT: 85.3ms (62.9ms - 129ms)
 測定中RTT: 227ms (12.5ms - 566ms)
上り回線
 速度: 1.965Mbps (245.7kByte/sec) 測定品質: 85.9 接続数: 1
 測定前RTT: 27.9ms (12.9ms - 56.9ms)
 測定中RTT: 24.9ms (12.3ms - 83.3ms)
測定者ホスト: **.***.*.***.shared.user.transix.jp
測定時刻: 2018/6/30 22:09:03
-----------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/
=================================================================

＞So-net、私はIPv6にしてもダメ

これはIPv4 over IPv6にしてもだめという事でしょうか。？
IPv4 over IPv6を使わなければIPv6を利用しても通信速度は
IPv4の通信速度は速くなりませんよ。
確かso-netはＶ６プラスに変更されましたよ。
Ｖ６プラスを利用するには対応ルーターが必要ですよ。
ホスト名を見る限りＶ６プラスではありませんよ。
一度、Ｗｅｂサイトで確認されたら。

=== Radish Network Speed Testing Ver.5.3.3.0 β - Test Report ===
使用回線: NTT東 フレッツ 光ネクスト ギガファミリー・スマートタイプ
プロバイダ: とくとくBB
測定地: 宮城県仙台市青葉区
-----------------------------------------------------------------
測定条件
 精度: 高 接続数: 1-16 RTT測定: 速度測定前後/速度測定中
 データタイプ: 圧縮可能性低 測定クライアント: JavaScript
下り回線
 速度: 378.9Mbps (47.37MByte/sec) 測定品質: 95.9 接続数: 16
 測定前RTT: 11.0ms (10.6ms - 11.6ms)
 測定中RTT: 22.6ms (9.66ms - 228ms)
上り回線
 速度: 26.62Mbps (3.328MByte/sec) 測定品質: 88.5 接続数: 1
 測定前RTT: 10.9ms (10.7ms - 11.2ms)
 測定中RTT: 10.7ms (10.2ms - 11.9ms)
測定者ホスト: *************.v*.enabler.ne.jp
測定時刻: 2018/6/30 01:33:54
-----------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/
======================================================

=== Radish Network Speed Testing Ver.5.3.3.0 β - Test Report ===
測定条件
 精度: 高 接続数: 1-16 RTT測定: 速度測定前後/速度測定中
 データタイプ: 圧縮可能性高 測定クライアント: JavaScript
下り回線
 速度: 841.1Mbps (105.1MByte/sec) 測定品質: 98.2 接続数: 16
 測定前RTT: 3.94ms (3.84ms - 4.07ms)
 測定中RTT: 7.61ms (4.24ms - 10.7ms)
上り回線
 速度: 465.2Mbps (58.14MByte/sec) 測定品質: 96.7 接続数: 16
 測定前RTT: 3.93ms (3.81ms - 4.03ms)
 測定中RTT: 3.41ms (2.56ms - 12.4ms)
測定者ホスト: **********.stmb***.ap.nuro.jp
測定時刻: 2018/6/29 20:06:43
-----------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/
=================================================================

いい加減速度貼り付けはみんなの測定に張り付けるように

管理人　様

測定ページで「データの有効期限が切れているかアクセス権限がありません 戻る」、「パラメーターエラー」と表示されて計測できません。使用端末の不具合でしょうか、ご教示いただければ幸いです。

ご指摘ありがとうございます。

調査いたしましたところ、Androidの一部のバージョンのブラウザにおいて、データの受け渡し上の問題を生じているようです。
原因は現在調査中です。

ブラウザの動作の仕様変更または動作上の不具合の可能性が考えられますが、問題の究明と解消には少し時間がかかるかもしれません。
ご不便をおかけいたしまして申し訳ございません。

どうぞよろしくお願いいたします。

調査の結果、端末上のcookieのデータに何らかの異常があったのではないかとみられます。
いったんブラウザ上のcookieの情報を削除することで復旧するようです。
弊社の端末にも同様の現象が見られたものがありましたので、何らかの問題がブラウザ側に有ったものと考えるのが妥当かと思いますが、その様な状況に至った原因は不明です。

お試しいただけないでしょうか。

よろしくお願いいたします。

詳細な掲示【14614-2】ありがとうございます。

掲示中段に…前略…データが安定して流れている時刻区間をシステムが判別…中略…時刻区間の"始点時刻から終点時刻までの間"に、"各TCPセッションを通過したデータサイズの合計"を"始点時刻から終点時刻までの時間"で除したものが測定の結果となります。…中略…複数使用しているのは、TCPのセッションであり、回線という概念のものではありません。…後略…とのことですが、

◎光1回線をマルチセクションの機能でデータをTCPセクション数を最大何セクションまで分割することが可能でしょうか？
◎Version 5 東京 β版の最適なTCPセクション数は何セクションでしょうか？
◎Version 5 東京 β版の「測定設定」・「接続数　最小・最大」は上記のTCPセクション数と解してよろしいか？または、測定の精度向上のために複数回線を接続し測定していると解してよろしいか？
◎NUROの「上り/下り　最大10Gbps」＆「上り/下り　最大6Gbps」のTCPセクション数は何TCPセクションと推察されますか？

掲示後段の…前略…測定用のサーバー間のインターネット経路の転送速度…中略…サーバー側にも限界性能があり、サーバー側の限界性能を超える場合は、経路の転送能力ではなく、サーバーの能力を測定する…中略…クライアントPCの能力が不足する場合はPCの処理能力を計測する…後略…とありますが、

◎「みんなの測定結果」の東京版でNURO測定結果が「1.9Gbps」前後の掲示されているのを見るとどこかの能力が不足していると思われますが、
　　当方のPC、プロバイダーのCOMMUFAのサーバーの能力、インターネット経路の能力のいずれかが不足していると推定されますか？

お忙しいところ恐縮ですが、5点について掲示ください。

ご質問に関してですが、少しイメージいただいているものと実際が異なることがあるように思われます。

まず、用語に関してですが、セッションという単語が出てきますが、これはプロトコルと呼ばれる通信を行う上でのデータの授受に関する取り決めの中で、通信開始から、通信終了までの一連の手順の流れ全体を一つのまとまりととらえる場合のそのまとまりを示す一般的な単位です。そのため、セッションという単語は、TCPセッション以外にもいろいろな場面で利用されます。インターネット関係で、一般の利用者がよく接するものとしては、PPPoEセッションというものがあり、これも物理回線上に形成される論理接続の一種を表すものですが、TCPセッションとは全く異なる概念のものです。
PPPoEセッションはPPPoEセッションを接続できるようにすること自体が、IPSのサービスなため、IPSやキャリアのサービス提供上の仕様として最大2接続までといった制限がつく場合がありますが、TCPセッションにはそういった制限がつけられることは通常はほぼないと思っていただいて結構です。
回線を流れるデータはパケットという単位で、粒としてふるまうもので、その粒をあたかも流れのように扱えるようにするのがTCPで、その仮想的な流れのひとまとまりがTCPセッションです。これは、道路上を行き先が雑多な車両が行きかう中に、路線という名前で路線バスが運行されるような状況に近いものです。路線は仮想的な回線であり、そこには定量的な人員の輸送力が形成されますが、道路を何らかの形で区分してバスを運行しているわけではないのと同じです。

> ◎光1回線をマルチセクションの機能でデータをTCPセクション数
>  を最大何セクションまで分割することが可能でしょうか？
TCPセッションを形成できる数は、プロトコルの仕組み上、数としては有限ですが、利用上は制限がないと捉えて差し支えはないような数です。

> ◎Version 5 東京 β版の最適なTCPセクション数は何セクション
>  でしょうか？
Version 5 東京 β版の場合、測定時のセッション数(接続数)は指定された範囲(初期状態では1-16)で最適なものをシステムが自動的に判断し適用します。
最適な数は利用環境と通信環境により異なるため、固定的に最適な数が決まるものではありません。
測定時に使用するセッション数を必要以上に増やすと、データ転送の効率低下や処理負荷の上昇につながるため、現在Version 5 東京 β版では、設定できる最大接続数は16として運用しております。

> ◎Version 5 東京 β版の「測定設定」・「接続数　最小・最大」
>  は上記のTCPセクション数と解してよろしいか？
はい、システムが使用するTCPセッションの接続数を決定する際に、この範囲で最適な接続数を選択する(自動的に)という範囲です。

>  精度向上のために複数回線を接続し測定していると解してよろし
>  いか？
精度という概念とは少し違うかもしれません。仮に1セッションで測定したとしても、その条件での通信にはその条件における転送速度があり、それを精度高く測定するという仕事もあります。
1セッションより複数セッションの方が、物理的な回線能力の限界に近づける場合が多いので、それをテストできるようにしたということです。上記の通り、使用するセッション数を多くしすぎると逆に効率が低下していきます。

> ◎「みんなの測定結果」の東京版でNURO測定結果が「1.9Gbps」
>  前後の掲示されているのを見るとどこかの能力が不足していると
>  思われますが、当方のPC、プロバイダーのCOMMUFAのサーバーの
>  能力、インターネット経路の能力のいずれかが不足していると
>  推定されますか？
ネットワーク回線は、道路のようなもので複数の用途や利用者にシェアされますので、一つのクライアント⇔サーバー間で物理回線の能力の上限までの転送速度が得られるような他に全く利用がないような運用はあまりされません。末端の区間であれば占有的に利用できる部分もありますが、共用される区間において物理回線の50%程度の転送速度でも得られるのであれば、その回線はかなり回線容量に余裕がある状態の運用と考えるべきではないかと思われます。物理回線の公称能力に達しないことは、多くの場合は道路に例えるなら、その道路を他の車も走っていたという状況かと思います。
なお、弊社のサーバー運用は、現在は500Mbps程度の測定能力を安定して提供できることを基準に運用しておりますので、これ以上の転送能力に関しては、弊社が運用しているサーバー側の能力の限界を計測している可能性もあります。また現時点では、約1.9Gbpsがサーバー側の物理的な限界となります(2GbpsにTCPのプロトコル上の損失を差し引いた値)。
1.9Gbpsが測定されたとすると、経路上の多くの部分が2Gbpsを大きく超えるネットワークで構成されていて、最も細い経路がデータセンタ内のサーバーに近い短い区間の2Gbpsで、かつたまたまこの2Gbpsの区間を使用する他のユーザーが存在しなかったということになるかと思います。

ご参考にしていただけますと幸いです。

下り320M契約で最高に調子がいいときでこれ。調子がいいときでも100～50mbpsを前後する。回線速度は常に不安定。
オンラインゲーム等をするには苦痛が伴う。当然動画の視聴時にもブツ切りである。どの時間帯でも安定感は皆無。
早くなったり遅くなったり、通信が一時的にきれることも頻繁にある。
金～日曜日の21～0時の時間帯には平均1mbps程度で酷いときは200kbps切ります。
ピーク時間帯にオンラインゲームをしていると国内サーバー（東京～東京）に接続していてもpingが60～100msで酷いときには200～3000msに達する。宇宙から接続しているのかと思うレベル。

参考程度に、NURO光1G契約で北米東海岸のサーバーに接続すると150～200ms。東京にあるサーバーに接続すると9ms～9msでとても安定している。JCOMの場合は最高のときで東京～東京20～40msと不安定である。

JCOMを利用すると尋常じゃないストレスに晒されることになります。
業者は320Mとはベストエフォートとほざくが企業努力をしているかは甚だ疑問で詐欺同然。
繰り返しになるが、酷いときには200kbpsをきる。JCOMは絶対に利用してはいけない。


== Radish Network Speed Testing Ver.5.3.3.0 β - Test Report ===
使用回線: J:COM 板橋
公称速度(下り): 300M
測定地: 東京都板橋区
-----------------------------------------------------------------
測定条件
 精度: 高 接続数: 1-16 RTT測定: 速度測定前後/速度測定中
 データタイプ: 圧縮可能性低 測定クライアント: JavaScript
下り回線
 速度: 128.0Mbps (16.00MByte/sec) 測定品質: 87.0 接続数: 6
 測定前RTT: 44.9ms (39.8ms - 51.0ms)
 測定中RTT: 107ms (20.3ms - 205ms)
上り回線
 速度: 7.207Mbps (900.9kByte/sec) 測定品質: 92.0 接続数: 1
 測定前RTT: 28.2ms (21.0ms - 36.7ms)
 測定中RTT: 113ms (39.4ms - 260ms)
測定者ホスト: **************.rev.home.ne.jp
測定時刻: 2018/6/18 00:08:39
-----------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/
=================================================================

=== Radish Network Speed Testing Ver.5.3.3.0 β - Test Report ===
使用回線: NTT西 フレッツ 光ネクスト マンション・スーパーハイスピードタイプ 隼 光配線方式
プロバイダ: ASAHIネット
測定地: 佐賀県佐賀市
-----------------------------------------------------------------
測定条件
 精度: 低 接続数: 1-16 RTT測定: 速度測定前後/速度測定中
 データタイプ: 標準 測定クライアント: JavaScript
下り回線
 速度: 397.1Mbps (49.64MByte/sec) 測定品質: 95.7 接続数: 16
 測定前RTT: 27.2ms (26.9ms - 27.5ms)
 測定中RTT: 33.7ms (29.4ms - 40.5ms)
上り回線
 速度: 96.12Mbps (12.02MByte/sec) 測定品質: 97.8 接続数: 16
 測定前RTT: 27.0ms (27.0ms - 27.0ms)
 測定中RTT: 22.9ms (21.0ms - 24.0ms)
測定者ホスト: o143094.dynamic.ppp.asahi-net.or.jp
測定時刻: 2018/6/17 22:30:48
-----------------------------------------------------------------
測定サイト http://netspeed.studio-radish.com/
=================================================================