Backup source of IT memo/linuxmemo4(No. 4) - Kei YOSHIMURA in AORI/IIS U-Tokyo

[[IT memo/linuxmemo4]]

- [[IT memo/linuxmemo]] for fuyu.ucsd.edu
- [[IT memo/linuxmemo2]] for isotope.ccsr.u-tokyo.ac.jp
- [[IT memo/linuxmemo3]] for isotope2.iis.u-tokyo.ac.jp->decomposed
*Setting up isotope2.ccsr.u-tokyo.ac.jp [#n1343bf2]

#contents
**specification [#od3291a8]
 Name: isotope2
 IP: 157.82.233.10
 Cluster system
 Headnode: Xeon X5680 (3.3GHz, hexa core) x2
 Compute node: [Xeon X5690 (3.46GHz, hexa core)x2]x4
 Storage: /data:8TB, /data1:11TB, /data2:11TB, /data3:9TB
 Network: InfiniBand QDR (MPI/NFS)
 OS: RedHat Enterprise Linux 5 (Server)

** OS [#oc0ca5f6]
旧isotope2を生研からAORIに移設し、計算ノード、通信装置、ストレージを増設した。

** softwares [#o93ecf92]
大抵はisotope2からそのまま引き継げでいる。詳しくは[IT memo/linuxmemo3]参照。

** ganglia [#s0a3fe41]
- ノード負荷状況のモニター。http://157.82.233.10/ganglia から見れる（CCSR内のみ）。

** Benchmark [#af5ded83]
*** NCEP/SIO GSM [#ka320ddd]
-http://http://g-rsm.wikispaces.com のグローバルモデルのテスト。
-mvapich2+intelでコンパイル。
 Run1 (headnode only): 30.9s
 Run2 (node=1:ppn=8):  30.4s
 Run3 (node=2:ppn=4):  26.3s
 Run4 (node=4:ppn=2):  23.9s
となり、nodeをまたいだほうが高速な結果が出た。本当かいな？

*** NCEP/SIO RSM [#gfcc5d91]
-上記と同様、領域版のテスト。
-mvapich2+intelでコンパイル
 Run1 (node=2:ppn=12): 536.2s
 Run2 (node=3:ppn=8):  518.6s
 Run3 (node=4:ppn=6):  510.5s
GSMの結果と同様に、nodeをまたいだほうが高速。CPUのBandwidthがボトルネックである可能性大。（だが、気にならないレベル）

*** NICAM [#y0e400b8]
- GL5RL0, Isotope/River入り実験。10並列、72時間。
- mvapich2だとノードをまたぐジョブがうまく走らない。
 Run1 mvapich2 (node=1:ppn=10): 404s
 Run2 mpich1 (node=1:ppn=10): 401s
 Run3 mpich1 (node=2:ppn=5): 336s
結構、分散型と集中型に差が出た。

* Manuals [#rbdbd6cc]
-&attachref(103-Torque取扱説明.pdf);
-&attachref(301-MPI環境の使い方（クラスタ向け）v02.pdf);
Backup source of IT memo/linuxmemo4 (No. 4)
