もう接続して動作しているわけですが、やはり「ワープ係数 9」で動かしたいのが人情 でしょう。さらに速く、正しくする方法はないのでしょうか?
Linux のネットワーク機能は、デフォルトで何も"チューニング"して いない設定でもかなり強力です。それ以上何もする必要がないかもしれません。 しかし期待していたほど接続がおもわしくない場合、どこかに問題がある可能性が あります。"裏技"に心を引かれるよりもやってみる価値があるかも しれません。
とてもおおざっぱな目安ですが、最大同期速度 は参考になります。これは電話局にある DSLAM からの距離に左右されます。
0-12 K ft 0-3.6 km) - 2000 Kbps or more (8100 max for ADSL)
12-16 K ft (3.6-4.6 km) - 1500 Kbps -> 1000 Kbps
16-18 K ft (4.6-5.4 km) - 1200 Kbps -> 512 Kbps
18-?? K ft (5.4-?? km)nbsp;- 512 Kbps -> 28 Kbps or less :(
いずれにしても、影響を与えると考えられる要因はたくさんあります。 次世代 DSL はこの点や中継機能のような関連技術を確実に改善していく でしょう。
ネットワークのオーバーヘッド(TCP や ATM、イーサネット)によって、モデムが実行 可能な同期速度が 10 〜 20 % 落ちるでしょう。1500 Kbps での接続 ならば 1100 〜1300 Kbps 程度で動くと思います。これが現実の速度です。組み込み 済みのプロトコルのオーバーヘッドを調整する必要はありません。また、プロバイダ が提供する速度よりサービスの質を落としていれば、何をしてもそれ以上はあがり ません。 また―回線や信号の品質、それにともなう速度に対して影響 を与える要因は限りなくあります。その中には制御できるものもあります。
普通なら、デフォルトでインストールしている Linux で最適な性能がでるはずです。 WIndows 9x ユーザは TCP Receive Window (RWIN)を増やすことで劇的に速度が 上がります。しかしこれはあまりに初期値が小さすぎるために起こります。デフォル トの値が 32 KB である Linux に、これはまったく当てはまりません。
例外は、慢性的に接続待ちが起こる場合です。たとえば、近くにあるプロバイダの 接続ポイントがずっと使用に耐えないほどの遅延(250ms 以上?)を出している なら、 TCP Window を増やすと良くなるかもしれません。TCP Receive Window や それに関連した事柄については、 http://www.psc.edu/networking/perf_tune.html を見てください。
Receive Window はバッファで、データフローの制御に役立っています。これを極端に 小さくすると、ボトルネックとなって、スループットが低下してしまいます。この 値は、帯域幅と遅延によって左右されます。遅延はあなたが良く 通信する相手とのラウンド・トリップタイム(RTT)の平均値として計測できます。これは pingを使って測定できます。たとえば Linux のデフォルトの値は 32 KB ですが、これは速度で 2 Mbps までに対応でき、遅延は 125ms 程度になります。 これが 1.0 Mbps ならば、遅延は 250ms となるでしょう。この値をあまり大きくし 過ぎると、スループットが逆に落ちてしまいます。ですからこれ以上は大きくしない でください。
例をいただいたニュージーランドの Juha Saarinen 氏に感謝致します。
tcp のバッファを上手に活用するのに、"ネットワーク容量(bandwidth delay product。エンドポイントとのパイプの太さ)"という常套手段 があります。
Buffer size = Bandwidth (bits/s) * RTT (seconds)
私の場合だと、下りでおよそ 8 Mbps です。しかし ATM ネットワークは 〜 3.5 Mbps までしか接続をサポートしてません。私はインターネットの中でもはずれた所に位置 していますが、1,500 バイトという充分な大きさのパケットで、RTT を平均 250ms とするのに (3,500,000/8)*.25 = 106KB というバッファを設定する必要がありま した(即座に 128 KB でました。これで充分です)。
Receive Window は /proc ファイルシステムで動的に設定できます。設定したい バッファの大きさの 2 倍の値を入力する必要があります。
#echo 262144 > /proc/sys/net/core/rmem_default #echo 262144 > /proc/sys/net/core/rmem_max |
上記の例だと、実際は 128K という値を設定しています。Send Window もあわせて 設定しています。しかし Send Window は DSL 接続において Receive Window ほど 阻害要因にはなりません。
#echo 262144 > /proc/sys/net/core/wmem_default #echo 262144 > /proc/sys/net/core/wmem_max |
これらの値は sysctl を使っても設定できます。man を見て ください。
その他として、カーネルのオプションで推奨できる値は下記の通りです(主要なもの だけです)。これによって回線をぎりぎりチューニングします。
# sysctl -a net.ipv4.tcp_rfc1337 = 1 net.ipv4.ip_no_pmtu_disc = 0 net.ipv4.tcp_sack = 1 net.ipv4.tcp_window_scaling = 1 net.ipv4.tcp_timestamps = 1 |
"インタリーブ"は、ADSL で DMT 回線符号化を使った場合に用いる エラー制御のしくみです。DMT は ADSL の標準となっていて、ADSL で飛び抜けて普及 しているの方法です。インタリーブは、DSLAM 上で絶え間なく通信データを バッファリングし、エラー訂正を行います。この機能は、電話が問題を起こして しまうような、局から離れた回線で非常に効果を発揮します。下りではこのバッファ が接続上無視できない程遅延を起こしていまいます。ですからそれなり の回線品質であるなら、インタリーブは実質何もメリットはありませんし、 実際には不必要に遅くなるかもしれません。
インタリーブはパラメータで調整でき、電話会社が有効にしたり無効したり できます。電話会社のほとんどは、デフォルトでは有効にしているようです。 そうすることで回線を安定させ、テクニカル・サポートへの電話を減らせるからです。 しかし、ユーザすべてが、その犠牲になっているのです。
回線がインタリーブしているかどうかを確認し、またそれを変更するには どうしたらいいのでしょうか? 一般的には、1 もしくは 2 ホップ先に 対して traceroute をかけると 25ms 以内程度なら、インタリーブが無効に なっていると考えてほぼ間違いないと思います。 しかし他の要因、たとえば実際どの程度のホップ数があるかどうかといったことも あります。本当のことを知るには、電話会社の誰かに聞くしかありません。「言う は易し」でしょう。
"FastPath" DMTは、"インタリーブを無効にする" ことと同じ意味です。繰り返しますが、これは ADSL と DMT の組み合わせに だけ当てはまります。
同期がまったくとれなかったり、接続がまるでできなかったなら、このセクションを 読んでください。モデムの取り扱い説明書を読んで、モデムの LED が何を表して いるのかを確認してください(モデムの多くは、赤かオレンジ一色で光っている ことで、同期していないことを表しています)。
モデムの同期を表す LED が緑になったことがない。
自分で設置をした場合、DSL ジャックやスプリッタの配線がおかしいことが考え られます。また可能性として電話会社の標準的な POTS デバイスと違った配線に なっていることも考えられます。上記を参照してください。
モデムは Linux 対応製品ですか? イーサネットがインタフェースなら、問題は起こら ないはずです。しかし PCI や USB モデムの場合、同期するにはドライバが必要になる と思います。この点がうまく動作しない原因になっていて、いまだに PCI や USB モデム が Linux 対応していない理由となっています。
プロバイダに連絡して回線が準備できているか確認してください。誰かがへまを するのはよくあることです。確認のためにリモートから回線のテストを行えると 思います。DSLAM がダウンしていることもリモートから確認可能です。電話会社 は充分に承知しているはずです。
モデムの電源コードを抜いて、壁にかかっているジャックから DSL コードを 抜いてください。それを NID(電話ボックスの外部)内部にあるテスト用 ジャックに挿してください。電源を取るのに、延長コードが必要になるかも しれません。一時的に内部(宅内)の電話線への配線が切れます。こうすれば、 内部の配線や環境などの問題を回避するのに効果的があるはずです。NIC に 接続するイーサネット・ケーブルのテストを行うのに当たって、接続する必要 はありません(これはイーサネット・モデムにだけ当て はまります)。モデムはケーブルがつながっていなくともうまく同期できます (「言うは易し」です)。しかしもし可能なら、システムをモデムの状態が 見られるところに移動して、(可能なら、そこで)同期速度を測ってください。 これで動けば、恐らく内部の配線に何らかの問題があるか、DSL の線に電気的 な干渉が起こっていると考えられます。スプリッタと壁に設置してあるジャック の接続を確認してください。スプリッタを設置していないなら、配線がおかしな 所やジャックすべての不具合のある(たとえば腐食している ところ)接点、おかしな接合点、もしくは欠陥マイクロフィルタを捜して出して ください。
上記のテストで同期しなかったなら、回線が準備されていないか、モデムが 壊れているか、DSLAM が落ちているかのどれかです。PCI と USB モデムは、 同期するにはドライバをロードしておく必要があります。こういうわけで このテストはやや複雑になってしまいます。
マイクロフィルタを設置しているなら、一時的に取り去って、あわせて FAX 等の 電話会社のデバイスをすべて抜いてください。マイクロ フィルタが壊れていて、回線がショートしているかもしれません。
ここで問題となる症状は、NIC が認識できない、もしくはモジュールがロード できない、ifconfig がインタフェースをアップできない等、 その他もろもろのエラーについてです。
BIOS のプラグ&プレイを無効にしてください。BIOS 上では、"Microsoft 以外の OS" もしくは、それと似た表現になっていると思います。NIC が IRQ 0 に割り振られている場合もこの症状になる場合があります。"resource temporarily unavailable" というメッセージを表示するかもしれません。
cat /proc/interrupts と入力して、IRQ の競合を チェックしてください。NIC が IRQ を共有しているなら、別のスロットに移すか、 BIOS で IRQ の設定をいじってください。ISA カードならメーカーからセット アップ・ユーティリティを手に入れる必要があるかもしれません。それを使って IRQ を設定してください。このユーティリティを使うには、DOS でブートする 必要があるかもしれません。
ひょっとすると、正しいモジュールがロードできていないかもしれません。 /usr/src/linux/Documentation/* にあるカーネル・ ソースに付属するドキュメントを読んで、使用しているカードもしくは チップセットについて調べてください。また /usr/src/linux/drivers/net/*.cには、個々のチップセットに ついてのコメントや更新情報があります。困ったことに、数種のモジュールが 提供されているカードがいくつかあります。 tulip や 3Com のカードに当て はまるようです。ブート時のメッセージを見て、lspci -v でカーネルがカードをどう認識しているかを見てください。insmod や rmmod、modprobe を 使っていろいろなモジュールをテストできます。詳しい情報は、それぞれの man を見てください。
メーカーの Web サイトで Linux 関連のドキュメントを調べてください。もしくは、 Donald Becker 氏の サイト http://www.scyld.com/network/ で情報を集めてください。
Linux 用の NIC ドライバは、モジュールにしない方がうまく動く、という 報告があります。すなわち、モジュールにしないで、コンパイルしてカーネルに 組み込んでしまいます。
またカードやドライバがおかしくて、不調であることも考えられます。他のカード に交換してみてください。高価で高性能なカードは必要ないことも付け加えて おきます。
このセクションは、モデムが同期し、NIC が認識でき、確かに動作していることを 確認していて、かつクライアン・ソフトウェアをインストールして何もエラーが 出ていないのにもかかわらず、ISP へ接続ができない場合に読んでください。 LED で実際にモデムの同期が取れているかを点検してください。IP 接続が失敗 したことは、ifconfig でアクティブな eth0 インタフェース (もしくは PPPoX 用の ppp0 インタフェース)が表示されないことでわかります。 もしくは、ping をゲートウェイや何処かに打つと、 'network unreachable' や似たようなメッセージを表示 します。
ISP が何のプロトコルを使っているかを確実に理解してください。DHCP や PPPoX を使っていますか? 間違いなく設定していることが大切です。テクニカル・ サポートに連絡する必要があるかもしれません。
DHCP を使っているなら、ISP は MAC アドレスによる認証を必要とします。 もしそうなら、正しいアドレスになっていますか? ISP もしくは自分が打ち 間違いをしていませんか? ISP がホスト名による認証を必要としていませんか? これは、"-h" というオプションをつけてコマンドを打てばわかり ます。
/var/log/messages を開いて、何か役に立ちそうな手がかり がないかを見てください。また、接続をはじめようとする時に tcpdump を動かしてください。tcpdump の出力はかなり 謎めいていますが、何らかの反応があるか否かは判断できるはずです。
PPPoX なら、ISP は ID として ユーザ名か、 ユーザ名@ドメイン名を使っていませんか?
デフォルト・ゲートウェイのアドレスに ping をかけてみてください。 デフォルト・ゲートウェイを見つけるには「route -n」 としてください。IP アドレス(たとえば 111.222.333.444 のように)で ping はできるが、ホスト名ではできない場合は、ネーム・サーバを /etc/resolv.conf で正しく設定していない可能性が あります。
PPPoE については PPPoE クライアントでイーサネットのインタフェースを アップしてください。ブート時にはアップしないでください。PPPoE が起動する 前にはデフォルトの経路が決して存在することがないようにしてください。 rp-pppoe の場合、/etc/ppp/options に何も記述がない ようにしてください。作者である David Skoll 氏が推奨しています。
ファイアーウォール(たとえば ipchains を使った)を動かしているなら、一時的 に落としてください。設定が間違っていたり、何もパケットを通していないかも しれません。
モデムを ISP 以外のところから購入したなら、適合していないモデルかもしれ ません。たとえば SDSL には SDSL モデムが必要です。また ADSL については、 CAP と DMT 符号化機能が必要で、これらは他の DSL と互換性がありません。
モデムは ISP が提供するサービスに合わせて設定する必要があるかもしれま せん。モデムは VCI や VPI、カプセリング等についての設定が可能になって います。 テクニカル・サポートに電話して、情報を得てください。普通モデムの設定は telnet か Web ブラウザを使って、モデムの IP アドレスにつないで行います。
このセクションは、接続はうまくいったものの同期がとれなかったり、同期が 断続的に切れたり、同期速度が著しく落ちてしまったり、"同期はしているが インターネットを利用できなかったり"、といった場合に読んでください。 (高級なモデムであれば、同期速度を示す機能を持っていますし、普通は telnet や Web ブラウザを使って確認できます。マニュアルを見てください)。
同期が切れる現象は DSLAM か回線(宅内外とも)もしくはモデムに問題がある場合に 発生します。DSLAM は一般的に"カード"を複数の"スロット "に入れるようになっています。たとえば、Alcatel DSLAM カードはカード 単位に接続を 4 回線できるようになっています。カードがおかしくなると 最大 4 ユーザが被害を被ります。ポイントは、同期が切れる故障が非常に限られた 範囲のものであることです。広範囲なユーザに影響が出るネットワーク障害とは 異なります。同期の問題は電話会社の問題であり、ISP には関係ありません。 サービス契約を ISP と結んでいるなら、電話会社にコンタクトが取れる ISP の担当者にコンタクトをとってください。 【訳註: DSLAM のカードは、こんな 形 です】
同期速度が低下したり、DSL の信号が切断したりするケースは、様々な問題を引き 起こします。そのような状態では最高速度を得ることはどうやっても無理でしょう。 しかしその症状が自分側の問題なのか、プロバイダ側なのか、はっきりしている わけではありません。
たとえば、宅内の配線接続がいいかげんならパケットが落ちてしまい、再送が起こって しまいます。こうなると実際にスループットが落ち、接続が低下してしまいます。 これはネットワークの問題として従来から存在しているパケット・ロスと考えがち ですが、DSL においては回線不良や信号減衰、もしくはモデム自体の問題によって 起こる可能性があります。
試してみた方がいいことをいくつか。
モデムの電源スイッチを切って、すぐに入れ直してください。電源ボタンもしくは スイッチを切って、壁のジャックに接続しているケーブルを抜いて 30 秒程おいと いてください。時間がたったら電源を入れて、ジャックに挿しなおしてください。 これで強制的に再同期します。PCI モデムの電源を落とすには、あいにくリブート するしか手がありません。これでモデムに起因する"同期はするが、 インターネットを利用できない"という状況が解決するかもしれません。 他の状況でも同様に直るかもしれません。
モデムから何からすべてを NID に移動して、宅内の配線すべてを迂回するなら、 上記のセクションを見てください。 状況がこれで改善したなら、問題は宅内のどこかにあります。改善しないなら電話 会社の問題です。
RFI 狩り―DSL は他から影響を受けやすい信号です。影響を与えるものが非常に たくさんあります。RFI(Radio Frequency Interference)は、自宅やオフィスに あたりまえに存在していて、信号強度を弱めたり、同期を断続的に切断したり、 同期速度を落としたりする原因になります。これを簡単にテストするには AM ラジオ が使えます。どこかきれいに受信できる局にチューニングしてください。どこで もかまいません。AM ラジオは RFI を検出できます。それは AM ラジオが DSL の信号と同じような周波数を使っているからです。RFI があると"ベーコン を炒める"ような音がする状態になります。コンピュータの電源装置に 近づけてみてください。同じような状態になるはずです。遠ざけるとすぐに 聞こえなくなります。これで RFI で発生する音がどのようなものかわかると 思います。 まともな品質の電源装置は、軽度の RFI しかおこさないはずです―問題を起こ さない程度です。ガイガー・カウンターのようにラジオをモデムや DSL の配線の そばに持っていってください。同じ状況になれば原因を捜してください。怪しい ものは、電源装置や変圧器、安定器、電気モーター、調光スイッチ、高輝度 な照明です。モデムを移動し、ケーブルの配線を見直せば充分です。モデムと 壁のジャックの間をできるだけ近くするのも良い案です。 【訳註:ADSL の利用周波数は、上り方向と下り方向で異なります。上りは約 30 〜 140kHz です。下りは G.liteが 550kHz、フルレート 約 1104 kHzまで利用して います】
慢性的に同期がおかしくなる問題は、たいてい回線のどこかに問題があります。 ただ単に接続部分がいいかげんで、おかしな場所を見つけさえすれば、簡単に 直せる場合もあります。これは電話会社の優れた技術とはおよそ相容れない 状況がほとんどです。プロバイダに問い合わせをしてください。必要があれば 丁寧につっついてください。たらい回しになったら、担当ではなく上司を 呼び出しましょう。
DSL を利用できる距離ぎりぎりの位置にいて、同期が切れたり、つながったり するなら、"ホーム・ラン" の設置を行ってみてください。上記を見てください。これは信号や同期の条件が 限界に近い場合に効果があります。
サージ・プロテクタを使っているなら、それを外してみてください。DSL の信号 に影響を与えるものもあります。
近所にある AM ラジオ局や不法にアマチュア無線をしているものも似たような 周波数を扱っているので、悪影響を受けることが考えられます。一日の内でも ある回数だけ問題を起こす場合があります。たとえば局が夜になって出力を上げたり する場合などが考えられます。DSL 技術が優れた電話会社なら、この問題を最小限 にすることができると思います。ケースバイケースですが。
このセクションは接続はできているが、スループットが出ない問題を抱えている 場合に読んでください。つまり契約しているビットレートに対して、それに 見合ったスループットが出ていない場合や電話局からの距離がある場合に当ては まります。ここでいう"ネットワーク"とは、WAN を指します―ISP のゲートウェイとローカルのサブネットもしくはバックボーン等の間を指します。 限界に近い回線は同期速度が落ちてしまうことを忘れないでください。これは スループットにも影響を与えます。上記を見て ください。
"遅延"と"パケット・ロス"が捜し求めている 2 つの 要因です。両者とも ping や traceroute といった標準的に使われるネットワーク・ツールを使えばかなり簡単に計測できます。 どちらが回線上で起こったとしても。パフォーマンスに影響を与えます。遅延は "反応の早さ"や"待ち時間"を意味します。現実には、 極端に遅延が起こっている場合にターゲットを当てます。 というのも、多少の遅延は常に存在しているからです。パケット・ロスは、相手に 到達するまでのどこかでパケットのデータが落ちてしまうことです。TCP/IP は パケットが"落ちた"ことがわかると、落ちたデータを再送します。 これが起これば、実際明らかに遅くなってしまいます。パケット・ロスは理想的 には 0 % であるはずです。
日常使っている WAN 側の経路は、重要であるときちんと認識する必要があります。 traceroute を異なるサイトのいくつかにかけてみれば、はじめの数"ホップ "は同じようであることがわかると思います。これが ISP のローカルな バックボーンであり、その ISP の上流プロバイダへのゲートウェイです。 この件についての問題が何であれ、どのサイトに対しても、何をあなたがしよう としても、すべて影響を受けてしまいます。
パケット・ロスと遅延については、まず ping を 2、3 箇所に対して行って みましょう。可能なら少なくとも異なる 2、3 箇所に。そうすれば、パケット・ ロスや尋常でない極端な遅延が見つかると思います。
$ ping -c 12 -n www.linuxdoc.org PING www.linuxdoc.org (152.19.254.81) : 56(84) bytes of data. 64 bytes from 152.19.254.81: icmp_seq=0 ttl=242 time=62.1 ms 64 bytes from 152.19.254.81: icmp_seq=1 ttl=242 time=60.8 ms 64 bytes from 152.19.254.81: icmp_seq=2 ttl=242 time=59.9 ms 64 bytes from 152.19.254.81: icmp_seq=3 ttl=242 time=61.8 ms 64 bytes from 152.19.254.81: icmp_seq=4 ttl=242 time=64.1 ms 64 bytes from 152.19.254.81: icmp_seq=5 ttl=242 time=62.8 ms 64 bytes from 152.19.254.81: icmp_seq=6 ttl=242 time=62.6 ms 64 bytes from 152.19.254.81: icmp_seq=7 ttl=242 time=60.3 ms 64 bytes from 152.19.254.81: icmp_seq=8 ttl=242 time=61.1 ms 64 bytes from 152.19.254.81: icmp_seq=9 ttl=242 time=60.9 ms 64 bytes from 152.19.254.81: icmp_seq=10 ttl=242 time=62.4 ms 64 bytes from 152.19.254.81: icmp_seq=11 ttl=242 time=63.0 ms --- www.linuxdoc.org ping statistics --- 12 packets transmitted, 12 packets received, 0% packet loss round-trip min/avg/max = 59.9/61.8/64.1 ms |
上記は問題がない、ごく普通の例です(このサイトへの経路は、あなたの場合とは 恐らくまったく異なるでしょう。したがって結果もまったく異なっているかも しれません)。 遅くなるような深刻で潜在的な問題はまったくありません。下記の例は問題が顕著 です。
$ ping -c 20 -n www.debian.org PING www.debian.org (198.186.203.20) : 56(84) bytes of data. 64 bytes from 198.186.203.20: icmp_seq=0 ttl=241 time=404.9 ms 64 bytes from 198.186.203.20: icmp_seq=1 ttl=241 time=394.9 ms 64 bytes from 198.186.203.20: icmp_seq=2 ttl=241 time=402.1 ms 64 bytes from 198.186.203.20: icmp_seq=4 ttl=241 time=2870.3 ms 64 bytes from 198.186.203.20: icmp_seq=7 ttl=241 time=126.9 ms 64 bytes from 198.186.203.20: icmp_seq=12 ttl=241 time=88.3 ms 64 bytes from 198.186.203.20: icmp_seq=13 ttl=241 time=87.9 ms 64 bytes from 198.186.203.20: icmp_seq=14 ttl=241 time=87.7 ms 64 bytes from 198.186.203.20: icmp_seq=15 ttl=241 time=85.0 ms 64 bytes from 198.186.203.20: icmp_seq=16 ttl=241 time=84.5 ms 64 bytes from 198.186.203.20: icmp_seq=17 ttl=241 time=90.7 ms 64 bytes from 198.186.203.20: icmp_seq=18 ttl=241 time=87.3 ms 64 bytes from 198.186.203.20: icmp_seq=19 ttl=241 time=87.6 ms --- www.debian.org ping statistics --- 20 packets transmitted, 13 packets received, 35% packet loss round-trip min/avg/max = 84.5/376.7/2870.3 ms |
パケット・ロスが 35 % もあります。またラウンドトリップ・タイムも同様 に遅くなっています。この例をちょっと調べるとわかるように、問題となるサイト への経路上にはバックボーンのルーターが 13 個あります。これが原因でこのサイト が遅くなっていますが、たまたま同じようなルーターに当たってしまった場合にだけ、 経路に影響が出ます。本当に問題なのは、いつも通過するルーターで同様な問題が 発生しているかどうかという点です。このゲートウェイや 2 番目のルーターもそう かもしれません。ランダムにサイトを選んで、traceroute を使って見つけ出してください。
$ traceroute www.bellsouth.net traceroute to bellsouth.net (192.223.22.134), 30 hops max, 38 byte packets 1 adsl-78-196-1.sdf.bellsouth.net (216.78.196.1) 14.86ms 7.96ms 12.59ms 2 205.152.133.65 (205.152.133.65) 7.90ms 8.12ms 7.73ms 3 205.152.133.248 (205.152.133.248) 8.99ms 8.52ms 8.17ms 4 Hssi4-1-0.GW1.IND1.ALTER.NET (157.130.100.153) 11.36ms 11.48ms 11.72ms 5 125.ATM3-0.XR2.CHI4.ALTER.NET (146.188.208.106) 14.46ms 14.23ms 14.40ms 6 194.at-1-0-0.TR2.CHI2.ALTER.NET (152.63.65.66) 16.48ms 15.69ms 16.37ms 7 126.at-5-1-0.TR2.ATL5.ALTER.NET (152.63.0.213) 65.66ms 66.18ms 66.39ms 8 296.ATM6-0.XR2.ATL1.ALTER.NET (152.63.81.37) 66.86ms 66.42ms 66.40ms 9 194.ATM8-0.GW1.ATL3.ALTER.NET (146.188.233.53) 67.87ms 68.69ms 69.63ms 10 IMVI-gw.customer.ALTER.NET (157.130.69.202) 69.88ms 69.25ms 69.35ms 11 www.bellsouth.net (192.223.22.134) 68.74ms 69.06ms 68.05ms |
最初のホップはゲートウェイです。実際には最初から 2 ホップは常に 同じで、最初から 3、4 ホップはたいてい同じです。つまり、どの 問題であっても、どこを訪れたとしても問題が起こり得ます(あなた自身の特定 の問題はこの例とは多少違っているかもしれません)。"通常の" ゲートウェイへの ping は、下記の通りです(私にとってはこれが普通です!)。
$ ping -c 12 -n 216.78.196.1 PING 216.78.196.1 (216.78.196.1) : 56(84) bytes of data. 64 bytes from 216.78.196.1: icmp_seq=0 ttl=64 time=14.6 ms 64 bytes from 216.78.196.1: icmp_seq=1 ttl=64 time=15.4 ms 64 bytes from 216.78.196.1: icmp_seq=2 ttl=64 time=15.0 ms 64 bytes from 216.78.196.1: icmp_seq=3 ttl=64 time=15.2 ms 64 bytes from 216.78.196.1: icmp_seq=4 ttl=64 time=14.9 ms 64 bytes from 216.78.196.1: icmp_seq=5 ttl=64 time=15.3 ms 64 bytes from 216.78.196.1: icmp_seq=6 ttl=64 time=15.4 ms 64 bytes from 216.78.196.1: icmp_seq=7 ttl=64 time=15.0 ms 64 bytes from 216.78.196.1: icmp_seq=8 ttl=64 time=14.7 ms 64 bytes from 216.78.196.1: icmp_seq=9 ttl=64 time=14.9 ms 64 bytes from 216.78.196.1: icmp_seq=10 ttl=64 time=16.2 ms 64 bytes from 216.78.196.1: icmp_seq=11 ttl=64 time=14.8 ms --- 216.78.196.1 ping statistics --- 12 packets transmitted, 12 packets received, 0% packet loss round-trip min/avg/max = 14.6/15.1/16.2 ms |
違う日に起こった同じゲートウエィでの問題は下記の通りです。
$ ping -c 12 -n 216.78.196.1 PING 216.78.196.1 (216.78.196.1) : 56(84) bytes of data. 64 bytes from 216.78.196.1: icmp_seq=0 ttl=64 time=20.5 ms 64 bytes from 216.78.196.1: icmp_seq=3 ttl=64 time=22.0 ms 64 bytes from 216.78.196.1: icmp_seq=4 ttl=64 time=21.8 ms 64 bytes from 216.78.196.1: icmp_seq=6 ttl=64 time=32.0 ms 64 bytes from 216.78.196.1: icmp_seq=8 ttl=64 time=21.7 ms 64 bytes from 216.78.196.1: icmp_seq=9 ttl=64 time=42.0 ms 64 bytes from 216.78.196.1: icmp_seq=10 ttl=64 time=26.8 ms --- adsl-78-196-1.sdf.bellsouth.net ping statistics --- 12 packets transmitted, 7 packets received, 41% packet loss round-trip min/avg/max = 20.5/25.6/42.0 ms |
41 % のパケット・ロスは、非常に高い値で、HTTP のようにサービスを たくさん上げているところでは、突然落ちてしまいます。サービスが動いていたと しても、とても遅くなります。
実際に起こったこの例を見ると、ゲートウェイの調子が悪いのだとと思いたくなります。 しかしふたを開けて見ると、電話会社のネットワークの DSLAM と ATM 部分に問題が ありました。したがってパケット・ロスや大きな遅延がともなう 1 ホップ目の問題は、 実際には最初のホップにたどり着く以前に発生してる場合がありえます。この問題を 切り分けるのに役に立つツールはありません。パケット・ロスは ISP や NSP と同様、 電話会社の問題でもあり得ます。
またモデム自身がパケット・ロスを起こす可能性も充分にあり得ます。この場合は、 モデムの電源を入れ直して、DSL の接続を 30 秒程落としてから再同期してみて ください。つまり接続上にあるどの場所―モデムや DSLAM、ATM ネットワーク― であってもパケット・ロスは起こり得ます。
ISP 上のネットワークに問題を発見したなら、テクニカル・サポートに問題点を 報告してください。
雑多なことをいくつか。
ロードできない Web サイトがいくつかある。これは PPPoX を使っているユーザが、MTU 値をあまりにも大きくしている場合に 起こります。 PPP0 デバイスの適正な値は 1492 ですが、そのサイトにたどり着くまでに 通過するすべてのルーターが、それより少なくとも 8 バイト小さい値を必要 としています。どこかのルーターが設定を間違っていれば、この問題に出くわ します。試しに MTU 値を小さくしてみてください。その LAN に接続している ホストはそれよりも小さい値―1452 もしくは 1412 にする必要があるかも しれません。
IP アドレスで ping を打つと問題ないが、ホスト名を を打つとおかしい場合。これは /etc/resolv.conf に あるネーム・サーバの設定が間違っています。クライアント(DHCP, PPPoX)の ドキュメントを調べて、テキスト・エディタで直接修正してください。ISP から DNS サーバの正しいアドレスをもらってください。
PPPoX が切れる。PPPoX の接続が運悪く切れがちに なります。PPP は回線状況に左右されやすく、断続的に接続が切れる結果と なります。これは何が問題で、どこで発生しているかを突き止めれば、 完璧に解決できます。別々のクライアントから試してみるか、現状のクライ アント付属のドキュメントでこの問題を調べてみてもいいかと思います。状況 がさらに悪化するようであれば、必要なら cron のジョブをしかけて、接続と 再接続を監視してください。
理由もなくインタフェースや経路がダウンしてしまう。 ifconfig や routeを使うと、インタ フェースや経路情報がどういうわけか消えてしまうなら、それはバグった NIC の ドライバのせいです。DHCP サーバが長時間にわたって応答を返さない場合も 同様な現象が起こります(クライアントのバグ? と思ったのは、Redhat から出た pump の初期バージョンでこのようなケースがあったからです)。
パフォーマンスやエラーが芳しくない(たとえば rht0 の)場合は、恐らく全二重、 半二重の不整合があると思われます。DSL モデムやルーターの大半は、通常半二重 に設定してあって、NIC も同様になっているはずです。
我々がまずはじめにするテストの 1 つに速度計測があります。これによって、予想 していたよりたいしたことがないのか、システムが好調なのかを確認できます。 正確に計測するのは思ったほどやさしくはありません。まず、ネットワークで使用 するプロトコルのオーバーヘッドで、10 から 20 % 理論値より遅くなります。 本当にどのくらい"遅くなる"かは、プロバイダのネットワーク構成に よって異なります。どこで、どのように値を計ったかに依存します。普通は、10 〜 20 % ぐらいになります。
インターネットにアクセスすると、ホップが増えるごとにわずかですがパフォーマンス が低下しています。現状それ程大きな影響はないと思います。理由はホップ数が それ程でもなかったり、コンピュータすべて―あなたのシステムや ISP のネット ワーク、上流の ISP のプロバイダ、そして接続相手―がすべて手入れの行き届いた 機械と同じように、何の支障もなく動いていたりする限りは。しかし、障害があれば ―その要因が幾重にも組み合わさっていることを、どうやって理解できるでしょう? 経路上のルータのどれかに挙動不審のインタフェースが 1 つでもあれば、誤った結果 になってしまうかもしれません。
確実に最大速度が出るであろう接続先は、加入している ISP―ISP のゲートウェイ です。そこへ一気に下ればいいだけで、登ることはないからです。 つまり理想的なテストは、できるだけ自宅から近いところです。 これは可能な限り予想できない要因の数々を取り除けるからです。ISP にローカル の ftp サーバがあるなら、テストを行う絶好の場所になります(traceroute をかけて、本当にローカルなのかを見てくだい)。
ISP が ftp サーバを持っていないなら、近くにある ftp サイトを探してください― ホップ数ができるだけ少ない方が好ましいです。また暇なサーバを見つけてください。 でないとおかしな結果になってしまいます。大きなファイルを見つけて― 10 MB 程度―、ダウンロード時間を計ってください。これを何日か続けてみてください。 また、別々の時刻で実行してみてください。サーバやバックボーンは、1 日の中で ある時刻に忙しい場合がありますので。こうしないと、結果がゆがみ、余計な要因を できるだけ排除する必要がでてくるからです。プロバイダは、バックボーンの トラフィックが重いことやボトルネック、遅くて負荷が重いサーバ等に対しては 保証していません。
テストするサイトがあちこちに散在しています。良いところもありますが、話半分 にしておいてください。あまりにも要因がたくさんあるために、テストによる接続や スループットのその場の計測値は正確であるとは言えません。これらのサイトでは、 あなたがそうあるべきだと思っている値の許容範囲にあるか、いないかという概要 をつかむぐらいはできるかもしれません。速度テストとしてお薦めは、http://www.dslreports.com/stest/0 と http://speedtest.mybc.com/ があります(両方とも Java が必要です)。他のサイトの結果よりは正確 だと思います。
ここで忘れてはいけないのは、およそ 10 % 〜 20 % のネットワーク 上のオーバーヘッドという制約を受けることです。例を上げておきます。私の場合 は、1472 Kbps という同期速度が上限です。ここからおよそ 15 % 落ちると 1275 Kbps となります。この同期速度は、電話局から 11,000 フィート(約 3,350 m) あることを考えると充分な速度で、実際には 1275 Kbps つまりおおよそ 1.2 〜 1.3 Mbps という、最大限のスループットが出ていると言ってもいいと思います ―他の条件が同じならばですが。dslreports.com の速度テストは下記の通りです。
Test running..Downloaded 60900bytes in 5918ms Downloaded 696000bytes in 4914ms First guess is 1133kbps fairly fast line - now test 2mb Downloaded 1679100bytes in 11090ms Upload got ok 1 bytes uploaded Uploaded 1bytes in 211ms Upload got ok 1 bytes uploaded Uploaded 1bytes in 205ms Upload got ok 1 bytes uploaded Uploaded 1bytes in 207ms Upload got ok 50000 bytes uploaded Uploaded 50000bytes in 2065ms Upload got ok 100000 bytes uploaded Uploaded 100000bytes in 3911ms ** Speed 1211(down)/215(up) kbps ** (At least 24 times faster than a 56k modem) Finish. |
1.211 Mbps という値は、サービスに対して現実的に期待していた値とほぼ同じです。 この結果に対して、トラブルシューティングやチューニング方法を探し出す気はあり ません。
警告!!!:私が加入している ISP は Web ページ用に キャッシュ・プロクシを立てています。これはこの手の Web ベースのテストの結果 をならしてしまいます。もしこれがなければ、テストの結果は明らかに遅くなって しまったでしょう。プロクシがあると、実際はプロクシからのスループット をテストしていることになってしまいます―テストサイトではなく。参考までに、 別の警告を。同時刻に別のテストサイトを計測しましたが、 600 〜 700 Kbps がコンスタントに出ました。まあ、ケースバイケースですが(いつもは、多かれ 少なかれ、それぞれ同じような結果が出ています)。2 つの異なるサイトから大きな ファイルを ftp して計測してください。私の場合は、約 1.25 Mbps でした。