7/8以降の速度計測はこちら（約定期blog）に書いていくことにした。
mg1：mcrn.jpの画像式速度計測（1セッション、約600KiBのファイル）
mg4：mcrn.jpの画像式速度計測（4セッション、約150KiBのファイル4つ同時）
fg10：FlashGetを用いてmcrn.jpに置いた約5MiBのファイルを10セッションでDL
12:12~12:22 JR和歌山駅前のKFC（ハイスピードエリア）
mg1
peak 307.54 avg 71.9
peak 281.31 avg 80.0
peak 286.39 avg 129.1
mg4
peak 553.45 avg 324.0
peak 518.22 avg 205.2
peak 530.06 avg 252.3
fg10
peak 1557.20 avg 913.57184
peak 1275.45 avg 858.76736
この時間帯に1セッション約80出ると考えると、4で320、10で800。計算が合う。
13:36~13:48 研究室（ハイスピードエリア）
mg1
peak 251.27 avg 60.5
peak 236.05 avg 63.3
mg4
peak 538.95 avg 255.9
peak 417.98 avg 219.1
fg10
peak 967.96 avg 681.49248
peak 1212.02 avg 681.49248
この時間帯に1セッション約60出ると考えると、4で240、10で600。こちらも近い。
どう考えてもセッション制御してるとしか思えないぞ。
13:57 研究室
fg20（※）
peak 1803.80 avg 約1184.45
※：FlashGetは10までだが、同じファイル（mcrn.jpとsephiebrain.jpに設置）を2つ同時にDLさせてみた。
運よくほぼ同時（片方が72秒、もう一方が73秒）に終わったので、72.5秒で2つ分DLしたとして計算。
この時間帯に1セッション約60出るとすると、20セッションで1200。
なんとこんなに多セッションでも比例関係が。
以下はあくまで想像だが、「1セッション○kbps上限固定」といったセッション制御はしていなくても、動的な制御はしてるんじゃないだろうか。
たとえば、MVNOで借りてる帯域をX、接続してるユーザをN、そのうちアクティブな（通信している）ユーザの率をU、1ユーザあたりの平均セッション数をSとすると、1セッションあたりの上限Lは
L=X/(N*U*S)
となる。
だが、UやSは変動するし、厳密に測定できるわけではないので、輻輳しないように大きく見積もらなければならない。
そのため、実際には回線が空いているのにセッション速度がクリッピングされてしまう。
ところが、複数セッションを張るとL*セッション数の分だけ帯域が使える。
もちろん、無線部の帯域か、Xの空きのいずれか小さいほうが上限となる。
ほぼ同じ時間帯に、同じサーバに対して同じプロトコルでアクセスしているのに、20倍もスループットが違うというのはおかしすぎる。
prinの輻輳もあるのかもしれないが、それ以外に何らかの制限がかかってるとしか思えない。
追記：
16:49 研究室
fg40
peak 2474.63 avg 1590.2394（※）
※：4ファイルの最短が1分35秒、最長が1分48秒と幅があるので、最長の1分48秒で計算。
さすがにこの辺が上限といった感じだな（1セッション平均約40kbps。ほぼ同時刻のmg1が132kbps、mg4が328kbpsと結構出てるので）。
結構リトライが発生してたのでサーバ側にかなり負担がかかってると思われる。
まあ、40セッションを1サーバに張るとか異常だからな。さくらからアカバン食らわないだろうな…((((((；゜Д゜))))))。
これでネットワーク側にはまだまだ余力があることがより確実に。
以前（6/30）はFG10でピーク3Mbps、平均2Mbps出てたので、40セッションでもそれに達しないということは制御パラメータが厳しくなってるとしか思えない。
まあ、こんなテストやりまくってたらパラメータ（上のほうの仮式のUやS）上げられてますます速度出なくなるかもしれない。
とりあえず言えることとして、セッション制御の有無ははっきりしないが、prinの輻輳なんてのはウソだな。
より負荷のかかるはずの超多重セッションで爆速なんだから。
あるいはもう改善したというのならそれはそれですごいんだが。