PM / RHiNET-VP

0 50 100 150 200

1 4 16 64 256 1k 4k 16k

Throughput (Mbyte/s)

Size (byte) 2-node

4-node 8-node 16-node

図8.6 PM/RHiNETにおけるノード数増加のスループットへの影響

がないが，転送サイズが1Kbyte^{以上では，}16ノードの場合のみわずかに低くなっている．

メッセージサイズが小さい場合，メッセージ受信関数が呼ばれてメッセージを受信してから再 度メッセージ受信関数が呼ばれるまでの間に次のメッセージが到着するため，無駄な受信バッファ の参照がほとんど生じずノード数の影響が出にくい．これに対し，メッセージサイズが1Kbyte^以 上の場合，ホスト上で受信バッファの先頭にPMのメッセージのヘッダが新たに書かれたことを 確認した直後に，メッセージのトレイラが格納される領域をアクセスしても，受信データのホス トメモリへのDMA転送が完了していないため，データ末尾の検出ができないという状況が発生 する．その際，PM/RHiNETは一旦受信をあきらめ，他のノードからのメッセージ到着確認を行 うが，図8.4に示したように，16ノードの場合，8ノードの場合に比べて受信バッファ全体を確認 して回るのに時間を要する．これがスループットの低下につながっているものと考えられる．

7.5.3節ではメッセージを到着順にホストメモリ上のバッファに格納する例を示した．この処理は，

PMのメッセージ通信の受信処理でほぼそのままの形で利用することができる．メッセージを一 続きのキューに受信することでPM/RHiNETで問題となったメモリ消費量の節約とメッセージ到 着検出時のオーバヘッドの削減が実現し，ノード数が増えた場合にもホストのメッセージ受信検 出によるオーバヘッドで2ノード間の通信性能が低下することはなくなるものと考えられる．

8.4.1 PM/RHiNET-VPの実装

PM/RHiNET-VPでは，PMの関数呼び出しを，7.5.3節の図7.10で示したVPUSHの各処理に対 応させることで実装した．

送信側のプロセスは，まずpmGetSendBufferでピンダウンされた送信バッファを確保し，ここ に送信するメッセージを書き込む．次にpmSendで，先ほど確保した領域のデータをVPUSH^用の SIDをつけて宛先ノードに対してPUSH^{で送出する．}

受信側ではpmReceiveが呼ばれた際に，解放ポインタと受信ポインタの比較をし，メッセージ の到着を検出する．両者に差がある場合，メッセージが到着していることになるため，メッセー ジからサイズ情報を読み取り，未受信のメッセージの先頭のアドレスをプロセスに渡す．その後，

pmReleaseReceiveBufferでバッファを解放する際に，解放ポインタを更新する．

8.4.2 PM/RHiNET-VPの特徴と問題点

PM/RHiNET-VPでは，単一の受信領域に全プロセスからのメッセージを受信できるため受信領

域を端から詰めて無駄なく利用することができ，プロセス数が増えた場合にも受信領域の容量を ノード数分増やす必要がない．また，メッセージの受信は受信ポインタと解放ポインタの差を取る だけで検出できることから，全受信領域を見て回る必要のあったPM/RHiNET^に比べ，pmReceive 発行時のホストの処理オーバヘッドを大幅に低減できることになる．

しかし，一方で，受信処理にソフトウェア処理が介在することから，受信処理のレイテンシが 大きくなってしまうという問題が予想される．また，VPUSHの都合上，PMのメッセージサイズ をRHiNET-2^のMTU以下に制限しなければならない点やReplier^{が機能しなくなるため}pull^応答 パケットの発行ができなくなりPM^のRMA機構を実装することができないといった点など，制 限が多く含まれる．これらにより，サイズの大きなメッセージの転送においてスループットを上 げにくいと考えられる．

8.4.3 PM/RHiNET-VPの機能通信性能の評価

8.3.2節で用いた評価環境と同様の環境で，以下の2^{項目に関して}PM/RHiNET-VP^の2^ノード 間の基本通信性能の評価を行った．また，比較のため，PM/RHiNETに関しても同じ条件で評価 を行った．

• ピンポン転送時のメッセージ通信のRTT

• バースト転送時のメッセージ通信のスループット

いずれも測定ではSCore^に付属のpmtestを用いた．また，メッセージ到着検出によるオーバ ヘッドを含まないよう，全体のノード数は2^とした．

PM^{のメッセージ通信の}RTT

PM/RHiNET-VP^とPM/RHiNET^のRTT^{の測定結果を図}8.7^に示す．

0 20 40 60 80 100

1 2 4 8 16 32 64 128 256 512 1k 2k 4k 8k

Round Trip Time (µsec)

Size (byte) PM/RHiNET

PM/RHiNET-VP

図8.7 PM/RHiNET-VP^とPM/RHiNET^{のメッセージ通信の}RTT

最小RTT^は，PM/RHiNET-VP^では25.5µsec^，PM/RHiNET^で10.1µsec^{となり，両者を比較す} ると，1Kbyte^以下ではPM/RHiNET-VP^のRTTの方が大きな値を示していることがわかる．

PM/RHiNETのRTTは，メッセージサイズが1Kbyteと2Kbyteの間で急激に増加している．これ は，PM/RHiNETに対して，RHiNET-2/SWの不具合を発生させないように通信量を抑えるチュー ニングが施されているためである．PM/RHiNETでは，メッセージサイズが2040byte^{を超えた時} 点でメッセージを複数回のPUSH要求で送り出すようにし，さらに次のメッセージをPUSH^で送 出する前に，push^{パケットに対する}ackパケットの到着を必ず待つことで，ネットワークの混雑 を低下させ，RHiNET-2/SWの不具合を回避している．

これに対し，2040byte以下のメッセージについては，ピンポンにおけるpingとpongのいずれ も単一のpushパケットで済み，pongに相当するpushパケットがackパケットの直後に到着する ため，次のping^{に相当する}pushパケットを送信するまでにackパケットを待つ必要は生じない．

よって，2040byte以下のメッセージサイズのPM/RHiNET^のRTT^は，RHiNET-2/SW^{の不具合を} 回避するためのチューニングの影響を受けていないと言える．

一方，PM/RHiNET-VP^のRTTは，メッセージサイズが512byte以下ではほぼ一定しており，メッ セージサイズに応じたレイテンシの増加は見られない．これは，PM/RHiNET-VPで用いている

VPUSHにおいて，ハードウェア処理によるDMA転送などと並列に実行されるソフトウェア処理

が転送サイズによらず一定の処理時間を要するためである．

PMのメッセージ通信のスループット

PM/RHiNET-VP^とPM/RHiNETのスループットの測定結果を図8.8^{に示す．測定は，}PM/RHiNET では8184byte^まで，PM/RHiNET-VP^では2040byteまでと，それぞれで送ることのできるメッセー ジサイズの最大値まで行った．

0 50 100 150 200

1 4 16 64 256 1k 4k 16k

Throughput (Mbyte/s)

Size (byte) PM/RHiNET

PM/RHiNET-VP

図8.8 バースト転送時のメッセージ通信のスループット

バースト転送時のスループットは，1024byte^まではPM/RHiNET^とPM/RHiNET-VP^{との間で差} が小さく，RTTとは異なる傾向を示している．これは，PM/RHiNET^では，8.4.3^{節で述べたよう} に直前に送信したpushパケットに対応するackパケットの到着を確認してからでないと次のpush パケットを送り出せないという制約が課されているために，バースト転送時にパケット送信の間 隔が空いてしまうことに起因する．