SB3Gｽﾋﾟｰﾄﾞﾃｽﾄ ～ mpw.jp
http://mpw.jp/sb3gspeed/select_agent.php?career_id=3mpw.jpのサイトは携帯ユーザーからすれば速度計測のサイトとしてもうお約束のサイトだろう。
私も良く見に行っていたし参考にさせてもらっている。
サイトの情報で過去に何度か記事を書いたこともある。
ただ気になることがある。
ソフトバンクの端末の計測について。
ソフトバンクのドメ携は長らく読み込みサイズが１ファイル300KBの制限がかかっていた。
それがドコモの端末のお下がりになり、ブラウザもドコモ仕様に合わされることになった。
というわけで今は500KB制限まで制限が緩和されれた。
その制限が外れてから結構な時間が経っている。
というわけでそろそろmpw.jpでのソフトバンクの端末の計測も500KBに対応してはどうかと思う。
W-CDMAは初速を遅くして、通信が進むほどに加速していくようになっているのでサイズが小さいと
どうしてもいい結果が出にくい。なので300KBから500KBにするだけで何割か高い結果になることが
期待できる。
個人的には500KB対応機種は500KB計測をしてもいいと思うのだけど。
ドコモはアプリ計測でアプリケーションプロセッサの電力を食うので高速通信しながら
アプリケーションを動作させるとある程度通信の速度を落としてプロセッサ用の電力を稼ぐ。
なのでドコモのアプリでの計測は生の速度が出ない。
ソフトバンクも300KBで不利なのでここでバランスを取っているのだろうか。
ちなみに一番生の速度で有利なのはＫＤＤＩです。
では何故ドコモがアプリ計測になっているのかというとドコモのブラウザがタコで
ファイル転送の終了が検地できないからです。なので仕方なくアプリで計測する羽目に。
ファイルの転送が終わったらイベントを発生してくれればいいだけなんですけどね。
なんでJavaScriptに対応したのにやってくれないのでしょうか。
たったそれだけのことで網に負担をかけずに世間からの見た目のダウンロード速度を上げる
ことができるのに。ドコモのこういうところがもったいないなぁ。
というわけでmpw.jpの管理人さん、ソフトバンクの件如何でしょう？
私はお手数でなければそろそろやってあげてもいいと思いますが・・・。
- 関連記事
-
- 2011/01/17(月) 19:16:06|
- 携帯
-
| トラックバック：0
-
| コメント：8
docomoのブラウザってタコなんですか…ブラウザ名何なんですかね…オクトパスに変更したらいいのに…
mpwも確かに500に対応してほしいですが(まぁ、自分の943Shは確か300のままですが)サーバーも補強しないといけなくなるのでなかなかアレでしょうね。
しかしソフトバンク、やはり遅い…
- URL |
- 2011/01/17(月) 19:19:29 |
- hatchet #-
- [ 編集]
ソフバンもAjaxが動くと聞いた事あるので、コレで速度計測したら？
大きなダウンロード容量ですよ。
ドコモだとmpwに記録されない不具合はありますが、計測結果は3000kbps程度よく出ます。
mpwのアプリ計測が2200kbps程度だと、Ajaxは3000kbpsだから実測に近いです。
フルブラ契約が必要な計測動作ですが。
[12/24 00:55] 4096kbps/N02C
http://mpw.jp/ajaxspeed/view_stat_domain.php?domain=docomo.ne.jp
よろしく
- URL |
- 2011/01/17(月) 20:16:18 |
- 朝焼け #N9MVqUQM
- [ 編集]
>hatchetさん
ブラウザはNetFrontなんですが、これはソフトバンクも同じなんですよ。
なのでブラウザ自身が悪いんじゃなくて、ドコモオリエンテッドな部分に何か問題が
有るんじゃないかと思います。
>朝焼けさん
確かに言われてみればそうですよね。
どうもAjaxはドメ携では処理が重くて受信後の処理で遅くなっていたイメージがあったので
どうも通信スピードが関係なくなっているイメージがあったので最近はチェックしていませんでした。
今はそれもほぼ解消されてきていたんですね。
- URL |
- 2011/01/17(月) 21:32:32 |
- 鈴 #GpEwlVdw
- [ 編集]
>鈴さん
処理の件はAjaxでなくともソフトバンクの一部携帯で起こりますね。
その結果ハイスピ対応でも上限が350そこそこなんてメーカーもあります。自分も使ってましたが、コンテンツキーの処理がとろいので95%でいったん止まってしまい結果MPWで低速度な結果になってしまいます。
まあ、それが一番大きかった熊のメーカーはソフトバンクから撤退してしまったようですがorz
- URL |
- 2011/01/17(月) 21:46:23 |
- hatchet #-
- [ 編集]
キャリアによって有利不利があるのは確かですが、それはそれとして
ソフトバンクに関しては、少なくともここ数ヶ月
「日別平均の平均値が総平均値以上になったことが無い」
という状況が続いています。
（ドコモとauは逆に総平均値以上をずっとキープしてます）
これに関しては、計測方法の違いなどは関係無く、
各キャリアのインフラの現状が如実に反映されるものですので、
総平均より上か下かでそれぞれのインフラの状況が読み取れますね。
ていうか、いつのまにか総平均でauがソフトバンクに並んでますね。
先月末に一度auが抜き返した後、ソフトバンクユーザーの猿計測で再度ソフトバンクが突き放していたのですが、
やはりインフラの状況差はごく少数の者が奮闘したところで覆せるものではないということですね（苦笑
- URL |
- 2011/01/17(月) 22:17:28 |
- みっく #-
- [ 編集]
500対応はUA見ると分かりますが、944SH、945SH、001SH、002SH、004SHの5機種だけですね。
- URL |
- 2011/01/18(火) 10:14:08 |
- 9kon #-
- [ 編集]
二年前の、１～８月に、９２０Ｔを使用してました。
ダウンロードが、よく固まり、特に、１～２月‥‥ウェザニュースの、お天気お姉さんの動画サイトで、ダウンロードが終わっても、コンテンツキーが、無くて不発弾に良くなりました。
ＳＢのインフラが、多少改善されたと、思っていましたが、東芝の方に問題が、あったんですね。シャープに買い替えての改善でしたか。
個人的には、シャープより、東芝の変換の方が、好きですが。
なるほど、納得しました。
しかし、９４５ＳＨのわざと君‥‥やりすぎだわ。私が、計るとそんなに出ないよ？
- URL |
- 2011/01/18(火) 20:46:11 |
- 愛知県の携帯マニア #-
- [ 編集]
W-CDMAが遅いんじゃなくて、TCPの特性でそうなっているのでは？
初速が遅いのは、スライディングウィンドウの拡大の速度が遅いからで、
スライディングウィンドウの拡大の速度は、サーバーとの伝搬遅延に依存します
FOMAの場合、domant処理とおぼしき特定の条件では、
TCPストリームが流れ出した時から数秒間は伝搬遅延が非常に遅いことが分かります。
（PC接続時に確認した動作ですが）
そういった部分がスループットの値を低くしているとは思います。
ちなみにSB/AUでは、domantぽい動作を確認出来たことはありません
また、途中でProxyやキャッシュサーバーを挟んでたりすると、
伝搬遅延が大きくなるため、スループットの加速は遅くなりますね。
理想で言えば、UDPストリームで検査するのが理想なんですけど、
端末もUDPプロトコルをサポートしてなかったりするので、
何の速さを比較してるのか時に分からなくなることもしばしば感じますね
最後にファイル転送をTCPレイヤーレベルで検知するのはブラウザの役目ではないと思います。
Javascriptをうまく使えば、検知できるのは確かですけど、それを作るのは、docomo等の通信事業者ではなくて、mpw.jpですよね？記事の記載ではそこが不明瞭かなと思いました。
webサーバー側でコンテンツの送信が終わったことを検知することは可能ですが、
私が試す範囲では、iモードについては、コンテンツの送信完了が異常に早いため、
mpw.jpではコンテンツ送信の終了を利用していないだけだと思います
（恐らく、imodeではTCP-proxyが中間にいると思われる。同様事象がAU/SBでは存在しないためAU/SBにはTCP-Proxyが存在しないと思われる）
（TCP-proxyの役目は、巷のWebサーバの多くはWirelessTCPをサポートしない可能性が高いため、
無線の利用効率を高めるために、TCP-Proxyを設置していると推測される）
参考まで
- URL |
- 2011/01/19(水) 03:21:23 |
- noname #JalddpaA
- [ 編集]
