Kodama's home / tips.

ネットワ−クの速度を調べる方法

"速さ" の意味は？

TCP/IP に使っている回線のスピードと云っても大まかには "バンド幅" と "レイテンシー" の2つがある.

遅延時間を測る

片道の時間遅れ(latency)を独立して測るのは困難. ping コマンドで往復遅延時間(round-trip time)を調べる.

GPS 時計 で高精度に時刻をあわせたマシン間でなら 往路と復路を別々に測れそうだ. ミリ秒単位(注. 1 ミリ秒は距離に換算して 200km 程度)までの測定なら基本レベルの演習問題かな？ GPS clock の同期精度は安直にサーバを作っても 数micro秒の精度が出る(距離に換算して数百m). (ヒント. RFC で NTP のプロトコルを調べる.) (ヒント. ntp のソースを見よう.)

データ帯域を測る

特定のサーバ間の速度の調査

以下の方法では, FTP サーバに試験用のファイルを作成しておいて get して所要時間を測定する. 前述しているように, 遠くのサーバとの間でこれをやると, 遅延時間を測定するのと同じ事になる.

回線の先に FTP(又は WWW)サーバが必要. LAN の試験なら簡単だが, 外部接続ではこれが一番のネックかも. 試験用ファイルのサイズに拘らないなら, 適当な anonymous FTP サーバ(又は WWW サーバ)から適当なサイズのファイルをダウンロードすると良い.

試験用のファイルを作る

回線能力にあわせて適当なサイズの試験用ファイルを作る. 1M, 10M などの切りの良いサイズなのは, 転送時間の見積もりがしやすいからで, 特に深い意味は無い.

例えば, 1M bps の回線の場合, 1M byte のファイルでは所要時間は最低でも 8秒程度. 10M byte のファイルだと, その 10倍だから約80秒かかる. 

$ dd bs=1024 count=10  if=/dev/urandom of=test_10K
$ dd bs=1024 count=100  if=/dev/urandom of=test_100K
$ dd bs=1024 count=1024  if=/dev/urandom of=test_1M
$ dd bs=1024 count=10240  if=/dev/urandom of=test_10M
$ dd bs=1024 count=102400  if=/dev/urandom of=test_100M
$ ls -l test_10M
-rw-r--r--    1 kodama   users    10485760  8月  2日  01:34 test_10M
      test_10M は 10M byte のサイズ

例: wget で速度を測定

  1. サーバ側のディスク読み込みなどの影響があるため, 数回繰り返し測定する.
  2. get した内容は /dev/null に捨てる(クライアント側のディスク負荷の影響を避けるため).
  3. 大まかな回線能力の見積もりをしておいて, 試験用ファイルのサイズの中から適当なものを選ぶ. ファイルが小さ過ぎると他のオーバーヘッドの影響が大きいので誤差が大きい. ファイルが大き過ぎると時間がかかり過ぎる. 良く分からないなら, 小さい方から test_10K, test_100K, test_1M, test_10M の順に試験してゆき, 時間がかかり過ぎない程度で止める.
  4. ネットワークやサーバにかなりの負荷がかかる. 他に迷惑をかけないように注意しよう.
  5. 上で作ったファイルでなくても, 適当な大きさのファイルが(ftp や www に)あればなんでも良い. 試験したい回線の向こう側に, ftp や http サーバを自分で確保するのは LAN の試験以外では難しい. 要するに適度に大きめのファイルがあればなんでも良い. ただし, 他人の利用との干渉が無い方が良いので混雑しているところや細い回線の先は避ける. 
$ wget -O - ftp://localhost/pub/test_10M > /dev/null
...略
21:23:08 (69.44 MB/s) - `-' を保存しました [10485760]

この例では, 内的な処理(localhost)だけで, ネットワークは使わないのでこれ(69.44[MB/s]＝555[Mb/s])が 今回使用した PC で測定できる最高速を表す. 最近の CPU なら, 内的な処理はもっと速いはず.

実際の測定では上の "localhost" の部分を FTP サーバ名に変えて使う.

スクリプト

スクリプトを作ったが, wget を直に動かして, 2-3 回観察するだけでも良いと思えて来た.

10M のファイルのダウンロードを n 回測定して, 速度の平均を表示するスクリプト. wget の起動時間などの影響で少し誤差が出る. ネットワークにかなりの負荷がかかる. 

#!/bin/sh
# Measure network speed.
# Usage:  net-speed.sh  (resource URL)  [iteration]

resource=$1
## e.g.
## ftp://localhost/pub/test_10M
## http://localhost/~test/test_10M

count0=$2
if [ -z "$count0" ] ; then count0=3; fi

# fill up server cache.
wget -O - -q ${resource} > /dev/null

LOOP(){
   count=0
   while [ $count0 -gt $count ]; do
      count=`expr $count "+" 1`
      (time wget -O - -q ${resource} > /dev/null)2>&1
   done
}
LOOP | gawk 'END{print "Average: "sum/n}/real/{gsub(/[ms]/," ");n=n+1;s=10/($2*60+$3);sum=sum+s;print s"[M/sec]"}'

速度低下や変動の原因

問題がありそうなら経路上にある要素を順に検討してゆく.

回線を高速化すべきか？どこまで？

上で説明した様に, 個々のTCPセッションに関しては, 帯域の限界は往復遅延時間で制限されてしまう. つまり,回線が太くなっても,相手の返事待ちでデータをケーブルに詰め込めないなら無意味. この境目となる距離はデータがケーブル中を占有する長さが目安となる.

以下では, TCP 通信を基準に回線の品質と使用目的について概説してみた. ただし, UDP を使ったビデオ配信などを行うなら,以下とは違った観点で評価する必要がある. 

Kodama's home / tips.