Google
 
ファイヤープロジェクト
ギガビットイーサネットの調査/計測/
GbEクラスタのnttcp計測結果
2003-08-04T15:00+09:00   matsu
GbEクラスタでnttcpを使用して通信性能を計測した.nttcpのバージョンは1.47である.
計測環境
この記事での計測では,特に断らない限りオプションには常に 
-n 102400 -f "%9b %8.2rt %12.2ct %12.4rbr %12.4cbr %12c %12.2rcr %12.2ccr"
と付けているが,表では省略する.また,GbEハブは特に断らないかぎりPLANEX-8Pで,100BASE-TXのネットワークのハブはNETGEAR-8Pである.
この記事での機器の略称一覧表.
NIC/HUB略称名称
NIC3COM3Com 10/100 Managed NIC 3C905CX-TX-M
NICMELCO-32Bメルコ LGY-PCI32-GT
NICMELCO-32メルコ LCI-G1000T32
NICMELCO-64メルコ LCI-G1000T64
HUBMELCO-8Pメルコ LSW-GT-8W
HUBPLANEX-8PPLANEX FXG-08TE
HUBNETGEAR-8PNETGEAR FS2108
チューニングなしの計測
まずはチューニングなしで計測してみた.実時間で計算したバンド幅を以下に示す. データ
このグラフは,縦軸に実時間に基づくバンド幅をとっている.各棒は左から順に
  1. 3COM クライアント側
  2. MELCO-32 クライアント側
  3. 3COM サーバ側
  4. MELCO-32 サーバ側
である.実時間で観るとMELCO 32は3COMの約1.7倍のバンド幅が出た.次にCPU時間で計算したバンド幅を以下に示す.
このグラフは,縦軸にCPU時間に基づくバンド幅をとっている.各棒は先程と同様.MELCO-32の3COMに対する優位性が,CPU時間ではかなり薄れている.また,送信側であるlocalにおいては3COMの方が良い値が出ている.そこで送受信を逆にしてみた.まず実時間のバンド幅.
このグラフは,縦軸に実時間に基づくバンド幅をとっている.-rオプションをつけたので,各棒は左から順に
  1. 3COM サーバ側
  2. MELCO-32 サーバ側
  3. 3COM クライアント側
  4. MELCO-32 クライアント側
である.先程とさほど変わらない.次にCPU時間でのバンド幅.
このグラフは,縦軸にCPU時間に基づくバンド幅をとっている.-rオプションをつけたので各棒は先程と同様.やはり送信側であるremoteで3COMの方がCPU時間でみた場合の方が良い値が出ている.3COMはWrite時のCPU負荷が極端に低いということになる.
MTUを代えてみる
先の計測ではMTUはデフォルトの1500だった.これはファーストイーサネットでよく設定される値である.GbEではこの値は最適ではないらしい.そこで,MTUを変更して計測してみたい.以下の様に設定できる(ハズ). 
ifconfig eth1 4000
でもなぜか 
SIOCSIFMTU: Invalid argument
と出る.犯人は
drivers/net/net_init.c
カーネルソース(eth_change_mtu)
tc902x.c,tc902x_tune.h
MELCO-32のドライバソース(TC902X_MAX_RXFRAME_SIZE)
のようだ.どうするんだ.いきなりトン座してしまった.否,そもそもMELCO-32はジャンボフレームに対応しているのだろうか.メルコのサイトの別のNIC(しかももっと安いやつ)は,わざわざ「ジャンボフレーム対応」って書いてあったので,MELCO-32も対応しているなら書いていそうなものだ.うーん,そうなるとMELCO-64も危うい.....おぉっとメルコのサイトからMELCO-32が消えている!!!!!!どういうことだ.とりあえずジャンボフレーム対応をうたっているLGY-PCI32-GTのドライバを落としてみた.雰囲気的にはやっぱり最大パケットサイズは1500に設定している感じだ.どういうことだ?!ハードウェアはジャンボフレームに対応しているけどドライバは対応していないということか?!!!!とにかくmtuの設定ができないのはifconfig,というかカーネルがハネているのかドライバがハネているのかぐらいは知りたい気がする.
バッファ長を変えてみる.
MTUはなんだか往生しているので,バッファ長を変えてみた. データ
なんかひどく見にくい模様のグラフだが,それに気づいただけよしとするか.このグラフは縦軸に実時間にもとづくバンド幅をとっている.各棒はバッファ長(-lオプションの値)が10240バイト,20480バイト,40960バイトの3本1組となっていて,左から順に
  1. 3COM クライアント側
  2. MELCO-32 クライアント側
  3. 3COM サーバ側
  4. MELCO-32 サーバ側
となっている.両NICともバンド幅は変わらない.また,データから実行時間が長くなっていることが分かる.送受信するデータ量を増やしただけなので当然か.あと,Bytesの表示がなんだか変.とにかくnttcpの-lオプションの値は通信性能には影響がないようだ.
送受信バッファサイズを変えてみる
なんだか値が改善されないが,どんどんやってみる.送受信バッファサイズを変えてみる. データ
このグラフは縦軸に実時間にもとづくバンド幅をとっている.変化を強調するため,90Mbpsから開始してるので注意.横軸は送受信バッファサイズ(バイト)である.送受信バッファを8バイトから128バイトまで大きくしていくと大きくバンド幅が改善された.この変化は3COMよりもMELCO-32の方が改善幅が大きい.ただし送受信バッファを128バイト以上に増やしてもさほど改善されない.
一つのリモートマシンに複数のマシンからnttcpしてみる
なんだか大きな効果が現れないギガビットイーサネットだが,くじけずに計測をつづける.今度はあるノードで 
nttcp -i
しておいて,別の複数のマシンからnttcpしてみるとどうなるかを計測してみた.まずノードDで 
nttcp -i
しておいて,ノードA,Bから同時に 
nttcp D
としてみた.データ.続いてノードA,B,Cから同時に 
nttcp D
としてみた.データ
両実験の結果グラフを以下に示す.
ここでようやくGbEの大きな効果が得られた.このグラフは,縦軸に実時間にもとづくバンド幅をとっている.各棒は赤色が3COMで青色がMELCO-32である.左からそれぞれ1対1,1対2,1対3でバンド幅を計測したものである.A,B,Cはそれぞれnttcpを実行したクライアントノードである.念のため各棒の説明を左から順に示す.
  1. 1対1(サーバ対クライアント)で計測.3COM.クライアントA.
  2. 1対1で計測.MELCO-32.クライアントA.
  3. 1対2で計測.3COM.クライアントA.
  4. 1対2で計測.3COM.クライアントB.
  5. 1対2で計測.MELCO-32.クライアントA.
  6. 1対2で計測.MELCO-32.クライアントB.
  7. 1対3で計測.3COM.クライアントA.
  8. 1対3で計測.3COM.クライアントB.
  9. 1対3で計測.3COM.クライアントC.
  10. 1対3で計測.MELCO-32.クライアントA.
  11. 1対3で計測.MELCO-32.クライアントB.
  12. 1対3で計測.MELCO-32.クライアントC.
グラフから分かる通り,クライアント数が2倍,3倍になると,バンド幅が3COMでは1/2倍,1/3倍になったのに対し,MELCO-32では1倍,0.7倍となり複数ノードからのアクセスがあっても,1クライアントあたりのバンド幅が下がりにくい.今までの結果では3COMに比べて1.7倍程度のバンド幅しか出ていなかった.これはMTU等のチューニング不足だと考えられる.すなわちハードウェア性能を引き出しきれていない.だが上のグラフから,複数ノードとの同時通信をすることで,ハードウェア性能を1対1通信の時よりも引き出すことが出来たと考えられる(1対3通信時のA,B,Cの結果を単純に足すと,MELCO-32はハードウェア的には最低でも422Mbps程度はあることになる).MTU等をチューニングしきれずに1対1の通信性能を引き出しきれていなくても,(今まで強調して来なかったが)デュアルプロセッサである本システムでは1対多通信は頻発すると考えられるので,総合ベンチマーク結果の向上にはある程度期待できる.
二組のnttcpを同時に実行してみる
次に二組のnttcpを同時に実行してみる.すなわちノードC,Dで 
nttcp -i
とし,ノードAで 
nttcp C
同時にノードBで 
nttcp D
とする.データ
両実験の結果グラフを以下に示す.
このグラフは縦軸に実時間にもとづくバンド幅をとっている.各棒は左から順に
  1. 1対1通信1組.3COM.クライアントA.
  2. 1対1通信1組.MELCO-32.クライアントA.
  3. 1対1通信2組.3COM.クライアントA.
  4. 1対1通信2組.3COM.クライアントB.
  5. 1対1通信2組.MELCO-32.クライアントA.
  6. 1対1通信2組.MELCO-32.クライアントB.
バンド幅に劣化はみられない.スイッチングハブPLANEX-8Pは1対1通信を二つ同時に行なっても十分に処理できることが分かった.
まとめと考察
不満の残るバンド幅
MELCO-32のバンド幅は3COMの1.7倍だった.10倍には遠く及ばない.
MTU
上を受けてMTUのチューニングをしたかったが,そもそもMELCO-32はJumbo Framesに対応していないようだ.すくなくともメルコ配布のドライバではMTUを1500以上に設定出来ないようにしている.Jumbo Frames対応のギガビNIC導入効果に興味がわく.
バンド幅とCPU負荷か
MELCO-32は3COMより実時間に基づくバンド幅は大きかったが,CPU負荷が高くCPU時間に基づくバンド幅が小さい.とくにWrite性能では3COMよりも劣る.
同時通信
MELCO-32では一ノードに対して二ノードからnttcpをかけてもバンド幅の劣化がない.これはデュアルプロセッサで一ノードあたり2プロセス走ることが多いであろう本システムにとっては効果が大きいと考えられる.また,同時通信することによって,ハードウェア性能としては,MELCO-32のバンド幅は最低でも422Mbpsはあることが分かった.
PLANEX-8Pの性能
PLANEX-8Pでは1対1通信を同時に二組行なってもボトルネックとならないことがわかった.8ポート全部を使用するとどうなるのかも検証したい.
送受信バッファ
送受信バッファのチューニングによって,MELCO-32は3COMよりもバンド幅が改善された.
おまけ
計測用BASHスクリプト. 
#!/bin/sh
ETH=
GETH=
FORMAT="%12b%12.2rt%12.2ct%12.4rbr%12.4cbr%12c%12.2rcr%12.2ccr"
N=102400
OPTION=-r

if [ "$ETH" = "" -o "$GETH" = "" -o "$FORMAT" = "" -o "$N" = "" -o "$OPTION" = "" ]
then
exit 0
fi

function setRemote(){
if [ "$1" = "3COM" ] 
then
REMOTE=$ETH
else
REMOTE=$GETH
fi
}

function execute(){
TEMPFILE=$(tempfile)
echo $OPTION > $TEMPFILE
OUTPUTFILE=result$(sed -e 's/ /_/g ' $TEMPFILE)-$1
rm $TEMPFILE
setRemote $1
nttcp -f $FORMAT -n $N $OPTION $REMOTE > $OUTPUTFILE
awk -f toHTMLTable $OUTPUTFILE
}

setRemote $1
execute $1
計測用BASHスクリプトから呼ぶawkスクリプト. 
/^l/ {print "<tr><td rowspan=\"2\">OPTION</td><td rowspan=\"2\">NIC</td><td>local</td><td>" $2 "</td><td>" $3 "</td><td>" $4 "</td><td>" $5 "</td><td>" $6 "</td><td>" $7 "</td><td>" $8 "</td><td>" $9 "</td></tr>"}
/^1/ {print "<tr><td>remote</td><td>" $2 "</td><td>" $3 "</td><td>" $4 "</td><td>" $5 "</td><td>" $6 "</td><td>" $7 "</td><td>" $8 "</td><td>" $9 "</td></tr>"}
TOPページ
不安火
Feature
Automake
AXIS
BASHスクリプト
Common Lisp
C++
C言語
GDB
GTK
Hibernate
JFreeChart
JNI
MPEG
NMS
Perl
PostgreSQL
Restlet
Spring
Struts
Taglib
XML
XUL
埋火
PC Cluster
ベンチマーク調査
ギガビットイーサネットの調査
MPIで並列プログラミング
Software
hpl_filter
SiteGenerator
GCMon
HKB
Software(En)
SiteGenerator
matsu(C)
Since 2002
Mail to matsu
Free Software Foundation Debian GNU/Linux Logo