5. パフォーマンス・チューニングとトラブルシューティング

5.1. チューニング

もう接続して動作しているわけですが、やはり「ワープ係数 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) - 512 Kbps ->  128 Kbps or less :(

いずれにしても、影響を与えると考えられる要因はたくさんあります。 次世代 DSL はこの点や中継機能のような関連技術を確実に改善していく でしょう。

ネットワークのオーバーヘッド(TCP や ATM、イーサネット)によって、モデムが実行 可能な同期速度が 10 〜 20 % 落ちるでしょう。1500 Kbps での接続 ならば 1100 〜1300 Kbps 程度で動くと思います。これが現実の速度です。組み込み 済みのプロトコルのオーバーヘッドを調整する必要はありません。また、プロバイダ が提供する速度よりサービスの質を落としていれば、何をしてもそれ以上はあがり ません。 また―回線や信号の品質、それにともなう速度に対して影響 を与える要因は限りなくあります。その中には制御できるものもあります。

5.1.1. TCP Receive Window

普通なら、デフォルトでインストールしている 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

5.1.2. インタリーブ

"インタリーブ"は、ADSL で DMT 回線符号化を使った場合に用いる エラー制御のしくみです。DMT は ADSL の標準となっていて、ADSL で飛び抜けて普及 しているの方法です。インタリーブは、DSLAM 上で絶え間なく通信データを バッファリングし、エラー訂正を行います。この機能は、電話が問題を起こして しまうような、局から離れた回線で非常に効果を発揮します。下りではこのバッファ が接続上無視できない程遅延を起こしていまいます。ですからそれなり の回線品質であるなら、インタリーブは実質何もメリットはありませんし、 実際には不必要に遅くなるかもしれません。

インタリーブはパラメータで調整でき、電話会社が有効にしたり無効したり できます。電話会社のほとんどは、デフォルトでは有効にしているようです。 そうすることで回線を安定させ、テクニカル・サポートへの電話を減らせるからです。 しかし、ユーザすべてが、その犠牲になっているのです。

回線がインタリーブしているかどうかを確認し、またそれを変更するには どうしたらいいのでしょうか? 一般的には、1 もしくは 2 ホップ先に 対して traceroute をかけると 25ms 以内程度なら、インタリーブが無効に なっていると考えてほぼ間違いないと思います。 しかし他の要因、たとえば実際どの程度のホップ数があるかどうかといったことも あります。本当のことを知るには、電話会社の誰かに聞くしかありません。「言う は易し」でしょう。

"FastPath" DMTは、"インタリーブを無効にする" ことと同じ意味です。繰り返しますが、これは ADSL と DMT の組み合わせに だけ当てはまります。

5.2. 設置上の問題

同期がまったくとれなかったり、接続がまるでできなかったなら、このセクションを 読んでください。モデムの取り扱い説明書を読んで、モデムの LED が何を表して いるのかを確認してください(モデムの多くは、赤かオレンジ一色で光っている ことで、同期していないことを表しています)。

5.2.1. 同期しない

モデムの同期を表す LED が緑になったことがない。

5.2.2. ネットワーク・カード(NIC)の問題

ここで問題となる症状は、NIC が認識できない、もしくはモジュールがロード できない、ifconfig がインタフェースをアップできない等、 その他もろもろのエラーについてです。

5.2.3. IP 接続上の問題

このセクションは、モデムが同期し、NIC が認識でき、確かに動作していることを 確認していて、かつクライアン・ソフトウェアをインストールして何もエラーが 出ていないのにもかかわらず、ISP へ接続ができない場合に読んでください。 LED で実際にモデムの同期が取れているかを点検してください。IP 接続が失敗 したことは、ifconfig でアクティブな eth0 インタフェース (もしくは PPPoX 用の ppp0 インタフェース)が表示されないことでわかります。 もしくは、ping をゲートウェイや何処かに打つと、 'network unreachable' や似たようなメッセージを表示 します。

5.3. 同期上の問題

このセクションは、接続はうまくいったものの同期がとれなかったり、同期が 断続的に切れたり、同期速度が著しく落ちてしまったり、"同期はしているが インターネットを利用できなかったり"、といった場合に読んでください。 (高級なモデムであれば、同期速度を示す機能を持っていますし、普通は telnet や Web ブラウザを使って確認できます。マニュアルを見てください)。

同期が切れる現象は DSLAM か回線(宅内外とも)もしくはモデムに問題がある場合に 発生します。DSLAM は一般的に"カード"を複数の"スロット "に入れるようになっています。たとえば、Alcatel DSLAM カードはカード 単位に接続を 4 回線できるようになっています。カードがおかしくなると 最大 4 ユーザが被害を被ります。ポイントは、同期が切れる故障が非常に限られた 範囲のものであることです。広範囲なユーザに影響が出るネットワーク障害とは 異なります。同期の問題は電話会社の問題であり、ISP には関係ありません。 サービス契約を ISP と結んでいるなら、電話会社にコンタクトが取れる ISP の担当者にコンタクトをとってください。 【訳註: DSLAM のカードは、こんな 形 です】

同期速度が低下したり、DSL の信号が切断したりするケースは、様々な問題を引き 起こします。そのような状態では最高速度を得ることはどうやっても無理でしょう。 しかしその症状が自分側の問題なのか、プロバイダ側なのか、はっきりしている わけではありません。

たとえば、宅内の配線接続がいいかげんならパケットが落ちてしまい、再送が起こって しまいます。こうなると実際にスループットが落ち、接続が低下してしまいます。 これはネットワークの問題として従来から存在しているパケット・ロスと考えがち ですが、DSL においては回線不良や信号減衰、もしくはモデム自体の問題によって 起こる可能性があります。

試してみた方がいいことをいくつか。

近所にある AM ラジオ局や不法にアマチュア無線をしているものも似たような 周波数を扱っているので、悪影響を受けることが考えられます。一日の内でも ある回数だけ問題を起こす場合があります。たとえば局が夜になって出力を上げたり する場合などが考えられます。DSL 技術が優れた電話会社なら、この問題を最小限 にすることができると思います。ケースバイケースですが。

5.4. ネットワークとスループットの問題

このセクションは接続はできているが、スループットが出ない問題を抱えている 場合に読んでください。つまり契約しているビットレートに対して、それに 見合ったスループットが出ていない場合や電話局からの距離がある場合に当ては まります。ここでいう"ネットワーク"とは、WAN を指します―ISP のゲートウェイとローカルのサブネットもしくはバックボーン等の間を指します。 限界に近い回線は同期速度が落ちてしまうことを忘れないでください。これは スループットにも影響を与えます。上記を見て ください。

"遅延""パケット・ロス"が捜し求めている 2 つの 要因です。両者とも pingtraceroute といった標準的に使われるネットワーク・ツールを使えばかなり簡単に計測できます。 どちらが回線上で起こったとしても。パフォーマンスに影響を与えます。遅延は "反応の早さ""待ち時間"を意味します。現実には、 極端に遅延が起こっている場合にターゲットを当てます。 というのも、多少の遅延は常に存在しているからです。パケット・ロスは、相手に 到達するまでのどこかでパケットのデータが落ちてしまうことです。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 上のネットワークに問題を発見したなら、テクニカル・サポートに問題点を 報告してください。

5.4.1. その他のネットワーク上の問題

雑多なことをいくつか。

5.5. スループットの計測

我々がまずはじめにするテストの 1 つに速度計測があります。これによって、予想 していたよりたいしたことがないのか、システムが好調なのかを確認できます。 正確に計測するのは思ったほどやさしくはありません。まず、ネットワークで使用 するプロトコルのオーバーヘッドで、10 から 20 % 理論値より遅くなります。 本当にどのくらい"遅くなる"かは、プロバイダのネットワーク構成に よって異なります。どこで、どのように値を計ったかに依存します。普通は、10 〜 20 % ぐらいになります。

インターネットにアクセスすると、ホップが増えるごとにわずかですがパフォーマンス が低下しています。現状それ程大きな影響はないと思います。理由はホップ数が それ程でもなかったり、コンピュータすべて―あなたのシステムや ISP のネット ワーク、上流の ISP のプロバイダ、そして接続相手―がすべて手入れの行き届いた 機械と同じように、何の支障もなく動いていたりする限りは。しかし、障害があれば ―その要因が幾重にも組み合わさっていることを、どうやって理解できるでしょう? 経路上のルータのどれかに挙動不審のインタフェースが 1 つでもあれば、誤った結果 になってしまうかもしれません。

確実に最大速度が出るであろう接続先は、加入している ISP―ISP のゲートウェイ です。そこへ一気に下ればいいだけで、登ることはないからです。 つまり理想的なテストは、できるだけ自宅から近いところです。 これは可能な限り予想できない要因の数々を取り除けるからです。ISP にローカル の ftp サーバがあるなら、テストを行う絶好の場所になります(traceroute をかけて、本当にローカルなのかを見てくだい)。

ISP が ftp サーバを持っていないなら、近くにある ftp サイトを探してください― ホップ数ができるだけ少ない方が好ましいです。また暇なサーバを見つけてください。 でないとおかしな結果になってしまいます。大きなファイルを見つけて― 10 MB 程度―、ダウンロード時間を計ってください。これを何日か続けてみてください。 また、別々の時刻で実行してみてください。サーバやバックボーンは、1 日の中で ある時刻に忙しい場合がありますので。こうしないと、結果がゆがみ、余計な要因を できるだけ排除する必要がでてくるからです。プロバイダは、バックボーンの トラフィックが重いことやボトルネック、遅くて負荷が重いサーバ等に対しては 保証していません。

テストするサイトがあちこちに散在しています。良いところもありますが、話半分 にしておいてください。あまりにも要因がたくさんあるために、テストによる接続や スループットのその場の計測値は正確であるとは言えません。これらのサイトでは、 あなたがそうあるべきだと思っている値の許容範囲にあるか、いないかという概要 をつかむぐらいはできるかもしれません。速度テストとしてお薦めは、http://www.dslreports.com/stest/0http://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 でした。