Renewed:
2003-04-17
スペックは何を見れば良いのか? | 回線利用率の見方 | トラフィックの見方
PINGやTRACEROUTEでスループットを測定する事の是非 | PING/tracerouteのツール
| | フレームリレーを評価
このページは、プロバイダが公表している情報のうち、プロバイダ選びに参考になるページをリンクしています。基本的に、加入者以外の人でも見れるページが対象です。
もし、他に御存知なら、自薦、他薦を問わず、webmaster@alice.ne.jpまで、ご連絡ください。
プロバイダからの情報リンクについて、プロバイダーの情報公開のページをご存知の方は、ご協力お願いいたします。
「プロバイダのURL」以外に最低1つは具体的で詳細なURLを書いて、送信してください。リンク切れの時は、リンク切れのチェックボックスをチェックするだけでもかまいません。
| 注１） | TOPページのみの情報は的確な処理ができません。 |
|---|---|
| 注２） | 的確な情報公開のページを持たないプロバイダーは、リストに入れていません。 |
| 注３） | 情報を入れて１週間たっても反映されない場合は、直接メールで補足説明をいただけると助かります。 |
| 注４） | フレーム表示に気をつけてください。フレームのURLではなく、出来るだけ直接的なURLを教えてください。 |
| 注５） | リンク切れなども教えていただけると助かります。 |
| 注６） | 頂いた情報は人間が処理するので、SPAMな情報は無駄骨です。 情報公開もしていないのに送ってくる人もいますが、絶対に載せません。 （って、SPAMする人がこんなの読んでいる訳無いか。） |
| 注７） | メールでのタレコミや自己申告も歓迎いたします。 |
プロバイダの回線に対するユーザーの不満の原因のほとんどは、これが出来ていない事に起因するようです。つまり、プロバイダの回線としてのスペックは、瞬間的に良くても意味が無いという事です。
＊帯域幅と利用者数の割合を尺度に使用するのは、その帯域を他の用途にも使用している場合、スループットの観点で正確でなくなる事が考えられます。
＊スループットは、バックボーンだけでなく、バックボーン以外の内部構造にも影響されます。
アクセスポイントごとの回線数に対する、使用されている回線の割合で表わされます。
もし、目的のプロバイダーが公開していない場合でも、他のプロバイダーとアクセスポイントを共有しているかもしれません。サーチエンジンで電話番号をキーワードにして共有しているプロバイダーを検索してみましょう、共有しているプロバイダーが公開しているかもしれません。
１００％になっていなくても、電話がつながらない事が有ります。目安としては、８０％を超えると、厳しいと思った方が良い様です。
良くわからないのですが、どのような状態をもって、「使用されている」とするのかが問題だと思います。電話回線がつながった状態でも、認証が終わらなければ、使用中とならない様なら、１００％になる前に電話回線そのものはビジーになる訳だし、、、。特にアナログ回線は、回線数が多いほど、１００％になる方がおかしいと思います。（ちゃんとピーク値をとっているかも関係するでしょうね）
アナログとISDNを合計して表示している場合は、意味が無いので無視しましょう。（例：ISDNはいっぱいなのに、アナログの利用者が少ないためあたかも接続回線が空いているように見える。）
優良なプロバイダの目安としては、全国のアクセスポイントで1週間の最大値が80〜90%以上出ていないことを確認すると良いでしょう。ただし、同一地域に複数のダイアル番号がある場合は例外です。（常に増強についての計画と厳しい基準に基づき、健全に運営されなければ、達成できないレベルですが、、、。）
特にEthernetなどのCSMA/CD方式のネットワークでは、トラフィックが１００％になるずいぶん前の段階にさしかかった時から、急速に飽和し始める。50%以下なら快適でしょう。
トラフィックのデーターは、実際に使用する経路と照らし合わせて、どこの部分を測定したかに注意をしながら見なければならない。
pingをすると、おまけに一定の大きさのパケットの往復時間が表示されます。この数値にはばらつきが有り、トラブルが有るのか、無いのか程度の事しか分からないと思った方が良いようです。tracerouteの数値も同様です。
pingの数値が変化する要因としては、（ここからの記述は大変怪しいのですが、、、）
- ルーター、ハブ、サーバー等の反応速度
- その瞬間にセグメント内にパケットが流れているかどうか
- パケットの衝突（コリジョンの発生）、、、この瞬間にパケットが運悪く出くわすと、そのパケットの転送には、極端に時間がかかる（次はぶつからないようにと、わざとランダムな時間を置いている）。
- コリジョンが頻繁に発生する原因は、ネットワークの容量が少ない事、そのセグメント内につながれたマシンの数が多い事、ftp等が一時的にネットワークを占領している事などが挙げられる。
- pingは、相手からパケットが送り返されてくる事から、相手の処理速度にも影響される。
で、私の心配していることは、まず、pingがコリジョンの影響を受けていないときの数値（あまりばらつきの無い数値）は、たまたまその瞬間に同一セグメントにデーターが流れていたかどうかや、目標または中継器のその瞬間の状態によって簡単に数十ms単位で変わることです。よって、これを使い、スループットを順位付けするのは、1回だけの計測では問題外ですし、定期的に行ったとしてもその差が非常に大きくない場合は、結論を出すことを避けた方が良いのではと思います。
つぎに、pingをかける相手の選択方法です。どんなに通常使う部分のスループットが良くてもpingをかける相手の部分が忙しければ、表示される数値が悪くなるということに注意すべきだと思います。また、これは外からネームサーバーやWebサーバーにかける場合に多いのですが、実際に使う経路をpingのパケットが通っていない場合も有るので注意が必要です。
最も問題なのは、経路が非対称の時にはユーザーがアクセスポイントに接続した時の状態は計測できないことがあるということです。インターネット側から経路の途中までしかpingしなかったなどの時には注意が必要です。（最後までpingしても結果が違うという体験をしたことがありますが、その根拠は調べきっていません。）
もう一つ心配なのは、pingを打つ側のコンピューターがpingのプログラム内で提示する時間は、本当に数ms単位で信頼性が有るのかどうかという疑問です。（これは、pingプログラムとハードウエアの実装に依存します。）
コリジョンが有った場合の数値の扱いですが、その数値にコリジョン回避のためのランダムなウエイトが入っていることに気を付けましょう。つまり、その数値の大きさを比べることは無意味だということです。（「コリジョン去って、またコリジョン」の場合は別ですが、、、）
*私は、pingでスループットを計ること自体を否定はしませんが、やり方については充分検討する必要が有ると思います。
*最も権威あるping、tracerouteに関する情報は、RFC*です（RFCJ*はこちら）。しかし、現実は実装に大きく依存しています。
*ネットワーク技術は急速に発展しています、この説明は比較的古く、特にコリジョンに関しての説明は時代遅れかもしれません。
- Windows95/NT
- DOSコマンドに標準装備の ping.exe tracert.exe
使用方法は、オプション無しで実行すると、表示されます。- WS_PING
(WS_PING is free to certain academic, U.S. government and non-commercial home users)
窓の杜 - Windows ForestのTCP/IPツールで手に入る。
単に、pingとtracerouteだけなら、こちらがお勧め。- CyberKit
(CyberKit is postcardware. )
窓の杜 - Windows ForestのTCP/IPツールで手に入る。- Macintosh/System 6.0以上
- WhatRoute
The WhatRoute Pageで手に入る。何が出来るの？
- PING
パケット（データーの切れ端）が通信先まで届いているかどうかが分かる。数回行うことで、届かない頻度（少ない方が高品質）が分かる。また、パケットが往復した時間（echoが戻って来るまでの時間）もおまけに表示される。
パケットが届いたことが分かるということは、相手先が（ある意味で）生きており、且つ、（一応）インターネット（IP層）が相手までつながっていると解釈できる。
traceroute
指定したIPアドレスやホスト名に到達するまでのIPルータのアドレスや付けられた名前、経過時間（パケットを受け取ったIPルーターから、「このパケットは無効になったよ」という、エラーメッセージが届くまでの時間）が表示される。相手先までのネットワーク的距離や経路情報などが分かる。また、桁違いに大きな経過時間を何度も表示する場所に注目することで、経路中のどこがトラブルを抱えているか推測できる。
注）会員専用のページは、基本的に除外しています。
数々の情報、ありがとうございます!お礼の言葉は、What's newにございます。
ネットワークのトラフィック！
ネットワークのスループット！
ジャンプメニュー（先頭）に戻る
ジャンプ >>>> A B C D E F G H I J K L M N O P Q R S T U V W X Y Z <<<< ジャンプ
各NOC間のCIR
各NOC間の遅延時間の保証
フレームリレーに接続しているバックボーンの帯域幅
This page written and maintained by Masamichi
Nishiwaki.
Questions, comments and others regarding this page,
please send to webmaster@alice.ne.jp
Copyright © 1996-2001 Masamichi Nishiwaki. All rights reserved.
This page has been visited times
since 1997/05/25
