現在地

B. Way to high speed (near 1Gbps or over 1Gbps) transfer

キャッシュ効果が期待できないメモリ容量以上サイズのファイル転送で GbE を使っていながら 1/10 程度の速度しか出ない場合、high speed をめざすためのヒントにしてください.

CPU speed

  1. ssh 環境は ssl による暗号・解読ともにかなり CPU に負荷がかかります. scp の通信速度が低い場合 top を同時に実行して負荷を確認すると 90% 近くの場合があり この様な状況であればデータ通信を暗号しない hscp に変えることでかなり速度向上します.
  2. hscp を使っても速度が出ず、top で負荷を確認して 100% 近い状況であれば、CPU 能力等ハードの限界である可能性が高いと思われます.
  3. 10GbE を使ってもなかなか10Gbpsはでません. 結構 CPU 律速になっている状況が観察されます. メモリバンド幅は十分な時代になりましたが、その他で律速条件が多々あってなかなか速度が出せません.

Disk speed

  1. ローカルディスクが、ディスク単体で構成している場合は速度が出ません. 単体ディスクの読み出しは 30-50MB/s 程度です. この状況では hscp を使っても Disk 律速でそれほど速度改善になりません. 数本ディスクで RAID 等の分散I/Oにより速度を 125MB/s 以上を確保すれば 1Gbps に近づける可能性が高くなります. 分散I/Oしていてもファイルシステムによって速度が出ない場合もあります. ベンチマークを キャッシュがきかないサイズ(メインメモリより大きなサイズ)で行って実測しておくと良いでしょう.
  2. NFS のボリュームも、速度がでないためディスク律速になります. 現在センター環境では ccfep1 からダウンロードする場合 /home で 800Mbps 程度、/week で 1Gbps 弱で律速となります. 複数同時通信が発生すれば、この帯域を分け合います.
  3. Download時に転送先を /dev/null で試して通信速度が大幅に変わる様であれば、書き込み側ディスク律速で速度劣化していると言えます.

Network speed

  1. ftp などの他の非暗号通信でも 10MB/s 未満の場合は、途中経路で 100Mbps で制限された箇所があるか調査が必要だと思われます.
  2. 安価な HUB に接続しているだけで 1Gbps の速度が出ないことがあります. netperf 等のツールを使って 1Gbps の速度が出せる環境か測定してみるのも良い方法です.
  3. 当然 network の利用が多ければ速度は出ません. UDT はパケットロスに弱い傾向があり、混雑していると大きく速度が劣化します. 昼夜で速度が大きく異なる場合は、日中の負荷を押さえるためにネットワーク接続経路等を検討する必要があると思われます.
  4. hscp で通信させる時に -I 1 をつけて実行させたときに NAK という項目で数十カウント以上が立て続けに表示される環境では、まず速度が出ません. これは何らかの原因で、UDT 通信的にパケットロスが発生していることを意味しています. 上記の混雑しているという状況以外に、夜でもロス状況が変わらない様であれば、途中経路上のネットワーク装置に問題が無いか精査する必要があると思われます. 
  5. 同時に複数通信を行うと、帯域を取り合って速度が出ない場合があります. センターから岡崎キャンパス内では10GbE化が完了しましたが、SINET3との接続でGbEのチャネリングになっているため、最悪1Gbps上に複数本の通信が押し込められることによる通信劣化が観察されています.

Network latency

  1. ping 等で調べることができる RTT (round trip time) が大きいと TCP を使った通信は 速度が確実に低下します. 遠距離通信では、通常の通信は速度が出ません. これが原因の場合 UDP を使った通信で劇的に速度が改善されることがあります. 岡崎から 20msec 程度の九大で 963Mbps の実績があります.
  2. RTT が 26msec を越えるあたりから UDT でもデフォルト設定値では速度劣化を起こす様子が遅延シミュレータを介した実験で観察されています. これを回避するには UDP を使ったプロトコル自身を見直す必要があると考えています. UDT を使っている現状で、設定値を変えれば改善できるのか、についてはまだ情報を持ち合わせておりません.

Window Size

  1. RWIN (Receive Window) を適切に(大抵の場合は現在値より大きく)設定すれば速度の改善が得られる報告があります. この効果は TCP 通信に限った話なので、UDP通信を使っている hscp にはあてはまりません. これと同じ効果は、hscp.conf 内の MaxWinSize や MaxBufSize を変更することで得られると思われます.

Buffer Size

  1. UDT ライブラリでは UDT のバッファサイズ、UDP のバッファサイズを変えられる様になっています. hscp.conf でそれらを変更することが可能です. あまり小さい値にすると著しい速度劣化が観察されますが、デフォルトで問題になった印象がありません.オプションスイッチ -I 1 を付けて実行したときに AvRcvBfSz(Average Receive Buffer Size) が 0 になる状況が観察される場合は、ディスクの書き込みが受信速度についていけない状況ですので、RecvBufSize を増やすことで改善できる可能性があります.

Packet Size

  1. GbEであれば、標準的な設定値で限界まで速度が出せますが、10GbEを使った場合、GbEをごくわずか越える程度でしか速度が出ないようです. この場合、UDT でのパケットサイズ設定を大きくする(ex. 1500 -> 60000)と、数倍程度早くなる傾向が見えています. 今のところ 2.5Gbps程度の実績があります. hscp.conf の UDTMaxPktSize を Server-Client 両方で変える必要があります.